qemu discuss - Dec 2007 - Updated tarball on Qemu Project Download Page

I''ve just uploaded a current CVS tarball of the QEMU-0.9.0 code from
today,
with a Solaris.README file which has been submitted to the qemu-devel at
nongnu.org
list, as well as a patch for compiling 32-bit i386 on an x86-64 host (works in
Solaris Express, though gcc hurls on S10U2, as previously documented).

Here are the known problems with the current code base:

1) on-going - the ctrl-alt-F, ctrl-alt-1 and other monitor/special key sequences
for QEMU on a SPARC system keyboard don''t work correctly.  I currently
don''t have a SPARC system to work from so I can''t debug this
problem.
It''s either in the keymaps or the libSDL key handling.

2) compiling all targets on an Solaris Express Build 77 causes a gcc coredump
when compiling target-mips/op_mem.c on an Intel quadcore 2.4Ghz.  Works
fine on a 64-bit Opteron running Solaris 10U2 and 32-bit running Solaris Express
Build 61.  Not sure if it''s a Build 77 issue, or a SSE3 instruction
issue on
the new system.

Ben
--
This message posted from opensolaris.org

Hey Ben,

Does the SPARC port really work? I thought I have seen mixed comments on 
this?

I would love to be able to run QEMU on SPARC and emulate x86 Operating 
Systems. In fact right now I have an application I want to evaluate that 
is native to Ubuntu Linux (or however it is spelled) and at first 
thought I figured I would try to run it on SPARC using BrandZ yet it 
looks like the SPARC/BrandZ port is not mature enough yet.

Then I thought about QEMU running on SPARC yet to be honest I thought I 
had also heard that the QEMU/SPARC port was not mature enough either?
 
Is SPARC/QEMU ready for prime time, or should I not bother? This project 
is one where I do not have a lot of time to be trail blazing yet if the 
SPARC QEMU port works well I could give it a try.

I might also be able to figure out the key mapping issues for you . . .

Thx!

Regards,

Tom

Ben Taylor wrote:
>I''ve just uploaded a current CVS tarball of the QEMU-0.9.0 code
from today,
>with a Solaris.README file which has been submitted to the qemu-devel at
nongnu.org
>list, as well as a patch for compiling 32-bit i386 on an x86-64 host (works
in
>Solaris Express, though gcc hurls on S10U2, as previously documented).
>
>Here are the known problems with the current code base:
>
>1) on-going - the ctrl-alt-F, ctrl-alt-1 and other monitor/special key
sequences
>for QEMU on a SPARC system keyboard don''t work correctly.  I
currently
>don''t have a SPARC system to work from so I can''t debug
this problem.
>It''s either in the keymaps or the libSDL key handling.
>
>2) compiling all targets on an Solaris Express Build 77 causes a gcc
coredump
>when compiling target-mips/op_mem.c on an Intel quadcore 2.4Ghz.  Works
>fine on a 64-bit Opteron running Solaris 10U2 and 32-bit running Solaris
Express
>Build 61.  Not sure if it''s a Build 77 issue, or a SSE3 instruction
issue on
>the new system.
>
>Ben
>--
>This message posted from opensolaris.org
>_______________________________________________
>qemu-discuss mailing list
>qemu-discuss at opensolaris.org
>http://mail.opensolaris.org/mailman/listinfo/qemu-discuss
>  
>

> Hey Ben,
> 
> Does the SPARC port really work? I thought I have
> seen mixed comments on  this?
It should.  I was running Solaris Express, DamnSmallLinux,
and Win98SE in QEMU VM''s last spring on a 4
socket 1.8Ghz US-IV+ Solaris 9 box with 16G RAM. :-)

What you may be hearing about is the Sparc Guests.
Those are getting better, but QEMU can still not boot
a Solaris Sparc guest yet.  If we ever find anyone with
some forth background who can work with the OpenBios
folks, we might get there.
> I would love to be able to run QEMU on SPARC and
> emulate x86 Operating Systems. In fact right now I 
> have an application I want to evaluate that 
> is native to Ubuntu Linux (or however it is spelled)
> and at first thought I figured I would try to run it on 
> SPARC using BrandZ yet it looks like the 
> SPARC/BrandZ port is not mature enough
> yet.
I''ll have to keep my eyes open about that.
> Then I thought about QEMU running on SPARC yet to be
> honest I thought I  had also heard that the QEMU/SPARC 
> port was not mature enough either?
I don''t think many people do it. The emulation on a Sparc
system a user is likely to have is gonna be slow.

However, the code base is so similar, and the only true
differences between sparc and x86 is in the math libraries
for 8 and 9.  10 doesn''t have any special features needed
for sparc or x86.
> s SPARC/QEMU ready for prime time, or should I not
> bother? This project is one where I do not have a lot 
> of time to be trail  blazing yet if the 
> SPARC QEMU port works well I could give it a try.
"Well" probably depends on your Sparc host.  I have
run DSL and Win98SE on a 2x450 Mhz U60 with
2GB of ram, and it''s "useable". Installing Solaris Express
on that box was a day job. That was painful....

A 900-1200 Mhz US-III (duals better) runs ok, and I was 
fortunate enough last spring to have access to a 1.8Ghz 
US-IV+ 4-way where I fleshed out the Sparc port on 
Solaris 9, so I''m pretty confident in the Sparc Hosting 
of Qemu.  The real  annoyance is going to be the hot-keys 
for getting into and out of the monitor on Sparc.
> I might also be able to figure out the key mapping
> issues for you . . .
Thank you.  That would be great for the community.

Let me know if you have any issues. 

Regards,

Ben
--
This message posted from opensolaris.org

Ben,

 >>I''ve just uploaded a current CVS tarball of the QEMU-0.9.0
code from
today,

Only changes to Qemu? Or also to kqemu?

The last time I tried Qemu with kqemu in a Xen Dom0 it crashed the 
system if kqemu was enabled

(tested with SUNWqemu 0.9.0__cvs20070220tue , the kqemu version used for 
the tests was 
kqemu-osol-1.3.0pre9-v0.2.tar.kqemu-osol-1.3.0pre9-v0.2.tar.gz)

regards

Bernd


Ben Taylor wrote:
> I''ve just uploaded a current CVS tarball of the QEMU-0.9.0 code
from today,
> with a Solaris.README file which has been submitted to the qemu-devel at
nongnu.org
> list, as well as a patch for compiling 32-bit i386 on an x86-64 host (works
in
> Solaris Express, though gcc hurls on S10U2, as previously documented).
>
> Here are the known problems with the current code base:
>
> 1) on-going - the ctrl-alt-F, ctrl-alt-1 and other monitor/special key
sequences
> for QEMU on a SPARC system keyboard don''t work correctly.  I
currently
> don''t have a SPARC system to work from so I can''t debug
this problem.
> It''s either in the keymaps or the libSDL key handling.
>
> 2) compiling all targets on an Solaris Express Build 77 causes a gcc
coredump
> when compiling target-mips/op_mem.c on an Intel quadcore 2.4Ghz.  Works
> fine on a 64-bit Opteron running Solaris 10U2 and 32-bit running Solaris
Express
> Build 61.  Not sure if it''s a Build 77 issue, or a SSE3
instruction issue on
> the new system.
>
> Ben
> --
> This message posted from opensolaris.org
> _______________________________________________
> qemu-discuss mailing list
> qemu-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/qemu-discuss
>
>   

-- 
Bernd Schemmer, Frankfurt am Main, Germany
http://home.arcor.de/bnsmb/index.html

M s temprano que tarde el mundo cambiar .
                        Fidel Castro

Thanks Ben!

Well I have a few higher end SPARC boxes that will probably suffice for 
testing. Does it matter which version of Solaris 10 I am running? I 
think 11/05 sounds familiar like the release I might be running, yet it 
has been a while, and I do not recall.

uname reports that I am running:

SunOS  5.10 Generic_118833-24 sun4u sparc

Is that a new enough release?

I''ll be happy to try it all out and maybe I can help with the key
mappings.

Is there a binary SPARC release I can download to quickly get started or 
would I need to compile from source? If there is a binary release please 
do point me to it and I''ll get started soon, if I have to compile from 
source and it is not a trivial build process I might not be able to jump 
on it as fast as I''d like to.

So far I have QEMU running on a Sol10 x86 box running the Oracle RH 
Linux Distro and everything seems to work fine so far. I downloaded a 
binary QEMU package though and did not compile it from source.

Thx!

Regards,

Tom




Ben Taylor wrote:
>>Hey Ben,
>>
>>Does the SPARC port really work? I thought I have
>>seen mixed comments on  this?
>>    
>>
>
>It should.  I was running Solaris Express, DamnSmallLinux,
>and Win98SE in QEMU VM''s last spring on a 4
>socket 1.8Ghz US-IV+ Solaris 9 box with 16G RAM. :-)
>
>What you may be hearing about is the Sparc Guests.
>Those are getting better, but QEMU can still not boot
>a Solaris Sparc guest yet.  If we ever find anyone with
>some forth background who can work with the OpenBios
>folks, we might get there.
>
>  
>
>>I would love to be able to run QEMU on SPARC and
>>emulate x86 Operating Systems. In fact right now I 
>>have an application I want to evaluate that 
>>is native to Ubuntu Linux (or however it is spelled)
>>and at first thought I figured I would try to run it on 
>>SPARC using BrandZ yet it looks like the 
>>SPARC/BrandZ port is not mature enough
>>yet.
>>    
>>
>
>I''ll have to keep my eyes open about that.
>
>  
>
>>Then I thought about QEMU running on SPARC yet to be
>>honest I thought I  had also heard that the QEMU/SPARC 
>>port was not mature enough either?
>>    
>>
>
>I don''t think many people do it. The emulation on a Sparc
>system a user is likely to have is gonna be slow.
>
>However, the code base is so similar, and the only true
>differences between sparc and x86 is in the math libraries
>for 8 and 9.  10 doesn''t have any special features needed
>for sparc or x86.
>
>  
>
>>s SPARC/QEMU ready for prime time, or should I not
>>bother? This project is one where I do not have a lot 
>>of time to be trail  blazing yet if the 
>>SPARC QEMU port works well I could give it a try.
>>    
>>
>
>"Well" probably depends on your Sparc host.  I have
>run DSL and Win98SE on a 2x450 Mhz U60 with
>2GB of ram, and it''s "useable". Installing Solaris
Express
>on that box was a day job. That was painful....
>
>A 900-1200 Mhz US-III (duals better) runs ok, and I was 
>fortunate enough last spring to have access to a 1.8Ghz 
>US-IV+ 4-way where I fleshed out the Sparc port on 
>Solaris 9, so I''m pretty confident in the Sparc Hosting 
>of Qemu.  The real  annoyance is going to be the hot-keys 
>for getting into and out of the monitor on Sparc.
>
>  
>
>>I might also be able to figure out the key mapping
>>issues for you . . .
>>    
>>
>
>Thank you.  That would be great for the community.
>
>Let me know if you have any issues. 
>
>Regards,
>
>Ben
>--
>This message posted from opensolaris.org
>_______________________________________________
>qemu-discuss mailing list
>qemu-discuss at opensolaris.org
>http://mail.opensolaris.org/mailman/listinfo/qemu-discuss
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/qemu-discuss/attachments/20071211/c310e83e/attachment.html>

---- "Thomas D. Briglia" <briglia at stanford.edu> wrote:
> Thanks Ben!
> 
> Well I have a few higher end SPARC boxes that will probably suffice for 
> testing. Does it matter which version of Solaris 10 I am running? I 
> think 11/05 sounds familiar like the release I might be running, yet it 
> has been a while, and I do not recall.
Most of the intitial work on Qemu for Solaris was done with Solaris 10
(both x86 and sparc).  When Juergen Kiel unpeeled the onion for
kqemu support for Solaris 10, 9, and 8x86,  at the same time, I had access
to the Solaris 9 sparc box, so I did some addtional work to make
sure it worked on Solaris 9/sparc.

So, no Solaris 10, is not an issue.  In fact, it''s really the preferred
OS.
> Is that a new enough release?
Easily.
> I''ll be happy to try it all out and maybe I can help with the key
mappings.
Wonderful.
> Is there a binary SPARC release I can download to quickly get started or 
> would I need to compile from source? If there is a binary release please 
> do point me to it and I''ll get started soon, if I have to compile
from
> source and it is not a trivial build process I might not be able to jump 
> on it as fast as I''d like to.
Read the Solaris.README in the tarball, and follow the links to the
opensolaris qemu project pages.  For Solaris 10, there''s only one
dependency.  libSDL.  Blastwave has one and  AFAIK, it has very
limited dependencies.  The webpage also has links on how to 
compile it yourself, but really, why bother. Blastwave has done it
for you.

At this point, assuming you''ve got the dependencies covered, you should
be good to go.  I''ve spent the better part of two years getting Solaris
support
for QEMU to the point where it''s really just, "configure, gmake,
gmake install".
> So far I have QEMU running on a Sol10 x86 box running the Oracle RH 
> Linux Distro and everything seems to work fine so far. I downloaded a 
> binary QEMU package though and did not compile it from source.
This stuff is not rocket science anymore.    You really do need the latest
code, and I''m not sure what version of the binary you got, but if
it''s the
one on opensolaris.org''s qemu project page, it''s almost a year
old.  The
amount of Solaris changes that went into CVS in the last year is *huge*.

Ben

---- Bernd Schemmer <Bernd.Schemmer at gmx.de> wrote:
> Ben,
> 
>  >>I''ve just uploaded a current CVS tarball of the
QEMU-0.9.0 code from
> today,
> 
> Only changes to Qemu? Or also to kqemu?
Kqemu hasn''t changed in 6 months.  Most of the changes for Solaris have
to do with configure/Makefile and occaionally the odd source file.
> The last time I tried Qemu with kqemu in a Xen Dom0 it crashed the 
> system if kqemu was enabled
Well, I have been meaning to try this, and hopefully will be able to spend
some time with it before the new year.
> (tested with SUNWqemu 0.9.0__cvs20070220tue , the kqemu version used for 
> the tests was 
> kqemu-osol-1.3.0pre9-v0.2.tar.kqemu-osol-1.3.0pre9-v0.2.tar.gz)
That is a very old version of QEMU and kqemu.  That version of kqemu will
only run on Solaris Express.  The source version in the downloads page
supports 8-current Solaris X86 i386, and Solaris 10-current for x86-64.

Building QEMU is now *very* easy.  Really.  All you need is libSDL, a working
gcc compiler (and this is documented in the tarball, and on the qemu project
page),  zlib, and gnutls.  Damn.  gnutls is part of Solaris 10, but I
haven''t tested
it on 9/x86.  Guess I gotta fire up the Dual Celeron 550... :-)

Ben

---- Brian Gupta <brian.gupta at gmail.com> wrote:
> Is it yet possible to setup a "Sparc zone" on an x86 box? (Excuse
my
> terminology, as I am not very familiar with qemu virtualization terms).
You mean, boot a Solaris Sparc instance in a QEMU guest running on
an x86 box?  Not Solaris Sparc.  Debian and a few other Sparc based
systems will boot, but the OpenBios code which is used for doing the
prom for the emulated Sparc guest, needs a forth expert to help debug
some "redirection" issues in the current OpenBios code which is
probably
the largest stumbling block to booting Solaris Sparc in a QEMU guest.

Ben
> 
> Thanks,
> Brian
> 
> On Dec 11, 2007 10:25 PM, Ben Taylor <sol10x86 at cox.net> wrote:
> 
> >
> > ---- "Thomas D. Briglia" <briglia at stanford.edu>
wrote:
> > > Thanks Ben!
> > >
> > > Well I have a few higher end SPARC boxes that will probably
suffice for
> > > testing. Does it matter which version of Solaris 10 I am running?
I
> > > think 11/05 sounds familiar like the release I might be running,
yet it
> > > has been a while, and I do not recall.
> >
> > Most of the intitial work on Qemu for Solaris was done with Solaris 10
> > (both x86 and sparc).  When Juergen Kiel unpeeled the onion for
> > kqemu support for Solaris 10, 9, and 8x86,  at the same time, I had
access
> > to the Solaris 9 sparc box, so I did some addtional work to make
> > sure it worked on Solaris 9/sparc.
> >
> > So, no Solaris 10, is not an issue.  In fact, it''s really the
preferred
> > OS.
> >
> > > Is that a new enough release?
> >
> > Easily.
> >
> > > I''ll be happy to try it all out and maybe I can help
with the key
> > mappings.
> >
> > Wonderful.
> >
> > > Is there a binary SPARC release I can download to quickly get
started or
> > > would I need to compile from source? If there is a binary release
please
> > > do point me to it and I''ll get started soon, if I have
to compile from
> > > source and it is not a trivial build process I might not be able
to jump
> > > on it as fast as I''d like to.
> >
> > Read the Solaris.README in the tarball, and follow the links to the
> > opensolaris qemu project pages.  For Solaris 10, there''s only
one
> > dependency.  libSDL.  Blastwave has one and  AFAIK, it has very
> > limited dependencies.  The webpage also has links on how to
> > compile it yourself, but really, why bother. Blastwave has done it
> > for you.
> >
> > At this point, assuming you''ve got the dependencies covered,
you should
> > be good to go.  I''ve spent the better part of two years
getting Solaris
> > support
> > for QEMU to the point where it''s really just,
"configure, gmake, gmake
> > install".
> >
> > > So far I have QEMU running on a Sol10 x86 box running the Oracle
RH
> > > Linux Distro and everything seems to work fine so far. I
downloaded a
> > > binary QEMU package though and did not compile it from source.
> >
> > This stuff is not rocket science anymore.    You really do need the
latest
> > code, and I''m not sure what version of the binary you got,
but if it''s the
> > one on opensolaris.org''s qemu project page, it''s
almost a year old.  The
> > amount of Solaris changes that went into CVS in the last year is
*huge*.
> >
> > Ben
> > _______________________________________________
> > qemu-discuss mailing list
> > qemu-discuss at opensolaris.org
> > http://mail.opensolaris.org/mailman/listinfo/qemu-discuss
> >
> 
> 
> 
> -- 
> - Brian Gupta
> 
> http://opensolaris.org/os/project/nycosug/

>
> ---- Bernd Schemmer <Bernd.Schemmer at gmx.de> wrote:
>> Ben,
>>
>>  >>I''ve just uploaded a current CVS tarball of the
QEMU-0.9.0 code from
>> today,
>>
>> Only changes to Qemu? Or also to kqemu?
>
> Kqemu hasn''t changed in 6 months.  Most of the changes for Solaris
have
> to do with configure/Makefile and occaionally the odd source file.
>
>> The last time I tried Qemu with kqemu in a Xen Dom0 it crashed the
>> system if kqemu was enabled
>
> Well, I have been meaning to try this, and hopefully will be able to spend
> some time with it before the new year.
>
>> (tested with SUNWqemu 0.9.0__cvs20070220tue , the kqemu version used
for
>> the tests was
>> kqemu-osol-1.3.0pre9-v0.2.tar.kqemu-osol-1.3.0pre9-v0.2.tar.gz)
>
> That is a very old version of QEMU and kqemu.  That version of kqemu will
> only run on Solaris Express.  The source version in the downloads page
> supports 8-current Solaris X86 i386, and Solaris 10-current for x86-64.
>
> Building QEMU is now *very* easy.  Really.  All you need is libSDL, a
> working
> gcc compiler (and this is documented in the tarball, and on the qemu
project
> page),  zlib, and gnutls.  Damn.  gnutls is part of Solaris 10, but I
> haven''t tested
> it on 9/x86.  Guess I gotta fire up the Dual Celeron 550... :-)
I feel like going totally extreme and booting the old sun4m Sparc 20 running
Solaris 8. That would make for the worst performance of a virtual machine
anywhere I would think. Could be kinda fun to try.

Dennis

Ugh!  I cringe when I hear Blastwave . . .

Don''t get me wrong Blastwave is invaluable yet only if you build 
everything on Sol 10 with just Blastwave packages.

I have been compiling stuff on Solaris for many years. In the old days I 
would either build my entire dev environment natively from scratch 
starting with gcc, or I would put together a dev env completely from 
sunfreeware. Either way I went fully one way or another.

Then with Sol10 when they bundled a real gnu style dev env I found that 
due to the compiler/linker mismatch issues if I tried to just add 
packages in from blastwave or sunfreeware I would get funky linking 
errors trying to build certain software bundles that would rely on a gcc 
linked with gnu gld.

So starting with Sol10 I found if you compile everything natively using 
their bundled dev environment, then everything actually works w/o using 
a single Blastwave or Sunfreeware package. 

So right now all my Solaris 10 environments are all running the latest 
openssl, openssh, openldap, kerb5, apache, apache apr, apache apr-util, 
Berk DB, syslog-ng, mysql, php, etc, etc, all compiled 64 bit yet using 
all the original Sol10 dev environment and base libs. Everything works 
great!

So as soon as someone says "oh you just need this one Blastwave package 
. . ." I then cringe ;-) cuz I know more than likely it will be more 
than just one package. I''ll also no longer have my complete 
"Blastwave/Sunfreeware" free environment. For security reasons I
really
prefer to use binaries that I natively compile myself.

I''ll see if I can compile the latest libSDL myself first using my 
standard dev environment before I decide if I have the time to proceed 
further.

I only asked for the binary SPARC QEMU cuz it seemed you guys did such a 
great job with the x86 version which was literally plug-n-play I figured 
I''d be lazy and see if there was a binary dist . . ;-)

Thx!

Tom

Ben Taylor wrote:
>---- "Thomas D. Briglia" <briglia at stanford.edu> wrote: 
>  
>
>>Thanks Ben!
>>
>>Well I have a few higher end SPARC boxes that will probably suffice for 
>>testing. Does it matter which version of Solaris 10 I am running? I 
>>think 11/05 sounds familiar like the release I might be running, yet it 
>>has been a while, and I do not recall.
>>    
>>
>
>Most of the intitial work on Qemu for Solaris was done with Solaris 10
>(both x86 and sparc).  When Juergen Kiel unpeeled the onion for
>kqemu support for Solaris 10, 9, and 8x86,  at the same time, I had access
>to the Solaris 9 sparc box, so I did some addtional work to make
>sure it worked on Solaris 9/sparc.
>
>So, no Solaris 10, is not an issue.  In fact, it''s really the
preferred OS.
>
>  
>
>>Is that a new enough release?
>>    
>>
>
>Easily.
>
>  
>
>>I''ll be happy to try it all out and maybe I can help with the
key mappings.
>>    
>>
>
>Wonderful.
>
>  
>
>>Is there a binary SPARC release I can download to quickly get started or
>>would I need to compile from source? If there is a binary release please
>>do point me to it and I''ll get started soon, if I have to
compile from
>>source and it is not a trivial build process I might not be able to jump
>>on it as fast as I''d like to.
>>    
>>
>
>Read the Solaris.README in the tarball, and follow the links to the
>opensolaris qemu project pages.  For Solaris 10, there''s only one
>dependency.  libSDL.  Blastwave has one and  AFAIK, it has very
>limited dependencies.  The webpage also has links on how to 
>compile it yourself, but really, why bother. Blastwave has done it
>for you.
>
>At this point, assuming you''ve got the dependencies covered, you
should
>be good to go.  I''ve spent the better part of two years getting
Solaris support
>for QEMU to the point where it''s really just, "configure,
gmake, gmake install".
>
>  
>
>>So far I have QEMU running on a Sol10 x86 box running the Oracle RH 
>>Linux Distro and everything seems to work fine so far. I downloaded a 
>>binary QEMU package though and did not compile it from source.
>>    
>>
>
>This stuff is not rocket science anymore.    You really do need the latest
>code, and I''m not sure what version of the binary you got, but if
it''s the
>one on opensolaris.org''s qemu project page, it''s almost a
year old.  The
>amount of Solaris changes that went into CVS in the last year is *huge*.
>
>Ben
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/qemu-discuss/attachments/20071211/97755ddb/attachment.html>

---- "Thomas D. Briglia" <briglia at stanford.edu> wrote:
> 
> Ugh!  I cringe when I hear Blastwave . . . 
<sigh>
> Don''t get me wrong Blastwave is invaluable yet only if you build 
> everything on Sol 10 with just Blastwave packages.
Obviously, you spend more time building package that already
exist on Solaris in several forms, for your reasons.

However, libSDL has no dependencies I can see from blastwave,
so it''s a very minor "upgrade".
> I have been compiling stuff on Solaris for many years. In the old days I 
> would either build my entire dev environment natively from scratch 
> starting with gcc, or I would put together a dev env completely from 
> sunfreeware. Either way I went fully one way or another.
Don''t get me started on sunfreeware....
> Then with Sol10 when they bundled a real gnu style dev env I found that 
> due to the compiler/linker mismatch issues if I tried to just add 
> packages in from blastwave or sunfreeware I would get funky linking 
> errors trying to build certain software bundles that would rely on a gcc 
> linked with gnu gld.
I don''t know anyone who builds anything using gcc with gnu gld on
Solaris.
It is well known that gnu ld and Solaris don''t get along, and
it''s one of the
reasons that blastwave stuff is linked using the standard solaris linker.

Sounds to me like you''re having LD_LIBRARY_PATH issues, or
you''re
not properly setting library path values with -L/-R.
> So starting with Sol10 I found if you compile everything natively using 
> their bundled dev environment, then everything actually works w/o using 
> a single Blastwave or Sunfreeware package. 
Peachy.  There are instructions on the opensolaris qemu project page on
how to build libSDL yourself.
> So right now all my Solaris 10 environments are all running the latest 
> openssl, openssh, openldap, kerb5, apache, apache apr, apache apr-util, 
> Berk DB, syslog-ng, mysql, php, etc, etc, all compiled 64 bit yet using 
> all the original Sol10 dev environment and base libs. Everything works 
> great!
Congrats.  Glad you have time to do so. Oh. of course.  You''re at
university.
Those of us with real jobs don''t have time to dedicate to building all
parts
of a system, just so we can be sure that it''s built to our
specifications, or
we''re on the bleeding edge.  My idea of bleeding edge these days is
QEMU CVS and Wine, just to make sure it keeps working. The rest of it
I''d rather rely on stock bog solaris or blastwave.

Sorry if I''m being a bit cynical, but when you get out in the real
world,
don''t expect your boss to give you buckets of time to build out an
entire
environment when it''s already available.
> So as soon as someone says "oh you just need this one Blastwave
package
> . . ." I then cringe ;-) cuz I know more than likely it will be more 
> than just one package. I''ll also no longer have my complete 
> "Blastwave/Sunfreeware" free environment. For security reasons I
really
> prefer to use binaries that I natively compile myself.
Go for it.  As I mentioned earlier, the how-to compile libSDL is on the project
page.
> I''ll see if I can compile the latest libSDL myself first using my 
> standard dev environment before I decide if I have the time to proceed 
> further.
> 
> I only asked for the binary SPARC QEMU cuz it seemed you guys did such a 
> great job with the x86 version which was literally plug-n-play I figured 
> I''d be lazy and see if there was a binary dist . . ;-)
Martin did some binary distrobutions, but I don''t.  There are too many
OS rev
issues, and I think it''s better for the community to be able to build
their own
code.  If something breaks in the compilation model, I can go fix it in the
source
and be done.  I really don''t want to play tech support for a binary
distrobution
model.  There are far too many versions that have to built now that kqemu is
supported from Solaris 8 to current, because each version has it''s
specific
kqemu module, and it''s specific hooks into it....

The tarball is almost to the point of typing ./configure; gmake; gmake install
(though it''s better to define a target destination, and which targets
you want
to build on).  Every special case I suspect has been covered, though I guess
I may be surprised when I try again on my Solaris 9/x86 box...

Besides, if you''re so good at compiling all that other stuff, QEMU and
libSDL
should be a no-brainer... :-)

Hey Ben,

Good Points! I might not have stated correctly though, I actually do use 
the Solaris linker but what I have found is that some software would not 
link because I think it was expecting gcc having been built with gld 
instead of the bundled Solaris gcc that was linked with ld. 

We have a complex tech stack here that relies on Kerberos, ldab, & 
Webauth and the only way to get the whole tech stack compiled end to end 
is to build it all myself carefully selecting the configure options for 
each package (eg: gssapi auth, etc).

I could never build our Tech Stack using just Blastwave stuff for not 
all the required options I need are given to configure when those 
packages are compiled at Blastwave.

I''ll agree though about Sunfreeware, once I found Blastwave I switched 
myself. 

Oh and actually many many yrs of my career was spent working at Sun & 
Oracle and I think I actually had more spare time at those ''real
jobs''
than I do at Stanford . . ;-)

I''ll take a look at libSDL today and see what I can do with it.

Thx!

T.

Ben Taylor wrote:
>---- "Thomas D. Briglia" <briglia at stanford.edu> wrote: 
>  
>
>>Ugh!  I cringe when I hear Blastwave . . . 
>>    
>>
>
><sigh>
>
>  
>
>>Don''t get me wrong Blastwave is invaluable yet only if you
build
>>everything on Sol 10 with just Blastwave packages.
>>    
>>
>
>Obviously, you spend more time building package that already
>exist on Solaris in several forms, for your reasons.
>
>However, libSDL has no dependencies I can see from blastwave,
>so it''s a very minor "upgrade".
>
>  
>
>>I have been compiling stuff on Solaris for many years. In the old days I
>>would either build my entire dev environment natively from scratch 
>>starting with gcc, or I would put together a dev env completely from 
>>sunfreeware. Either way I went fully one way or another.
>>    
>>
>
>Don''t get me started on sunfreeware....
>
>  
>
>>Then with Sol10 when they bundled a real gnu style dev env I found that 
>>due to the compiler/linker mismatch issues if I tried to just add 
>>packages in from blastwave or sunfreeware I would get funky linking 
>>errors trying to build certain software bundles that would rely on a gcc
>>linked with gnu gld.
>>    
>>
>
>I don''t know anyone who builds anything using gcc with gnu gld on
Solaris.
>It is well known that gnu ld and Solaris don''t get along, and
it''s one of the
>reasons that blastwave stuff is linked using the standard solaris linker.
>
>Sounds to me like you''re having LD_LIBRARY_PATH issues, or
you''re
>not properly setting library path values with -L/-R.
>
>  
>
>>So starting with Sol10 I found if you compile everything natively using 
>>their bundled dev environment, then everything actually works w/o using 
>>a single Blastwave or Sunfreeware package. 
>>    
>>
>
>Peachy.  There are instructions on the opensolaris qemu project page on
>how to build libSDL yourself.
>
>  
>
>>So right now all my Solaris 10 environments are all running the latest 
>>openssl, openssh, openldap, kerb5, apache, apache apr, apache apr-util, 
>>Berk DB, syslog-ng, mysql, php, etc, etc, all compiled 64 bit yet using 
>>all the original Sol10 dev environment and base libs. Everything works 
>>great!
>>    
>>
>
>Congrats.  Glad you have time to do so. Oh. of course.  You''re at
university.
>Those of us with real jobs don''t have time to dedicate to building
all parts
>of a system, just so we can be sure that it''s built to our
specifications, or
>we''re on the bleeding edge.  My idea of bleeding edge these days is
>QEMU CVS and Wine, just to make sure it keeps working. The rest of it
>I''d rather rely on stock bog solaris or blastwave.
>
>Sorry if I''m being a bit cynical, but when you get out in the real
world,
>don''t expect your boss to give you buckets of time to build out an
entire
>environment when it''s already available.
>
>  
>
>>So as soon as someone says "oh you just need this one Blastwave
package
>>. . ." I then cringe ;-) cuz I know more than likely it will be
more
>>than just one package. I''ll also no longer have my complete 
>>"Blastwave/Sunfreeware" free environment. For security reasons
I really
>>prefer to use binaries that I natively compile myself.
>>    
>>
>
>Go for it.  As I mentioned earlier, the how-to compile libSDL is on the
project
>page.
>
>  
>
>>I''ll see if I can compile the latest libSDL myself first using
my
>>standard dev environment before I decide if I have the time to proceed 
>>further.
>>
>>I only asked for the binary SPARC QEMU cuz it seemed you guys did such a
>>great job with the x86 version which was literally plug-n-play I figured
>>I''d be lazy and see if there was a binary dist . . ;-)
>>    
>>
>
>Martin did some binary distrobutions, but I don''t.  There are too
many OS rev
>issues, and I think it''s better for the community to be able to
build their own
>code.  If something breaks in the compilation model, I can go fix it in the
source
>and be done.  I really don''t want to play tech support for a binary
distrobution
>model.  There are far too many versions that have to built now that kqemu is
>supported from Solaris 8 to current, because each version has it''s
specific
>kqemu module, and it''s specific hooks into it....
>
>The tarball is almost to the point of typing ./configure; gmake; gmake
install
>(though it''s better to define a target destination, and which
targets you want
>to build on).  Every special case I suspect has been covered, though I guess
>I may be surprised when I try again on my Solaris 9/x86 box...
>
>Besides, if you''re so good at compiling all that other stuff, QEMU
and libSDL
>should be a no-brainer... :-)
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/qemu-discuss/attachments/20071212/5149ae0a/attachment.html>

Nice work with SDL, it compiled no problem, and I did not even have to 
read the README! ;-)

Actually first time it crapped out for I do not have audio enabled on my 
servers yet as soon as I deactivated audio in the configuration phase it 
compiled 64 bit no prob w/o a single Blastwave package, totally native 
Solaris dev env! ;-)

My normal dev env looks like:

PATH=/usr/sfw/bin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/usr/local/apr/bin:/usr/ucb:/usr/local/ldapcsdk-6.02/bin
LDFLAGS=-m64 -L/usr/local/ldapcsdk-6.02/lib -L/usr/local/ssl/lib 
-L/usr/local/lib/sasl2 -L/usr/local/lib
CPPFLAGS=-m64 -I/usr/local/ldapcsdk-6.02/include 
-I/usr/local/ssl/include -I/usr/local/include/gssapi 
-I/usr/local/include/sasl2
LD_LIBRARY_PATH=/usr/local/ldapcsdk-6.02/lib:/usr/lib/sasl2:/usr/local/BerkeleyDB.4.6/lib:/usr/local/ssl/lib:/usr/local/lib/sparcv9:/usr/sfw/lib/sparcv9:/usr/lib/sparcv9:/usr/local/lib:/usr/sfw/lib:/usr/lib:/usr/local/apr/lib
LD_LIBRARY_PATH_64=/usr/local/ldapcsdk-6.02/lib:/usr/lib/sasl2:/usr/local/BerkeleyDB.4.6/lib:/usr/local/ssl/lib:/usr/local/lib/sparcv9:/usr/sfw/lib/sparcv9:/usr/lib/sparcv9:/usr/local/apr/lib:/usr/local/lib
CFLAGS=-mcpu=v9 -m64 -O
LDSHARED=gcc -G -mcpu=v9 -m64
CXXFLAGS=-m64
CC=gcc -m64
CXX=g++ -m64
SASL_PATH=/usr/lib/sasl2
PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/sfw/lib/pkgconfig

Later on I will compile QEMU. If it goes as smoothe as SDL, then a 
double Kudos to you and all the other developers!

:-)

T.

Thomas D. Briglia wrote:
> Hey Ben,
>
> Good Points! I might not have stated correctly though, I actually do 
> use the Solaris linker but what I have found is that some software 
> would not link because I think it was expecting gcc having been built 
> with gld instead of the bundled Solaris gcc that was linked with ld. 
>
> We have a complex tech stack here that relies on Kerberos, ldab, & 
> Webauth and the only way to get the whole tech stack compiled end to 
> end is to build it all myself carefully selecting the configure 
> options for each package (eg: gssapi auth, etc).
>
> I could never build our Tech Stack using just Blastwave stuff for not 
> all the required options I need are given to configure when those 
> packages are compiled at Blastwave.
>
> I''ll agree though about Sunfreeware, once I found Blastwave I
switched
> myself. 
>
> Oh and actually many many yrs of my career was spent working at Sun & 
> Oracle and I think I actually had more spare time at those ''real
jobs''
> than I do at Stanford . . ;-)
>
> I''ll take a look at libSDL today and see what I can do with it.
>
> Thx!
>
> T.
>
> Ben Taylor wrote:
>
>>---- "Thomas D. Briglia" <briglia at stanford.edu>
wrote:
>>  
>>
>>>Ugh!  I cringe when I hear Blastwave . . . 
>>>    
>>>
>>
>><sigh>
>>
>>  
>>
>>>Don''t get me wrong Blastwave is invaluable yet only if you
build
>>>everything on Sol 10 with just Blastwave packages.
>>>    
>>>
>>
>>Obviously, you spend more time building package that already
>>exist on Solaris in several forms, for your reasons.
>>
>>However, libSDL has no dependencies I can see from blastwave,
>>so it''s a very minor "upgrade".
>>
>>  
>>
>>>I have been compiling stuff on Solaris for many years. In the old
days I
>>>would either build my entire dev environment natively from scratch 
>>>starting with gcc, or I would put together a dev env completely from
>>>sunfreeware. Either way I went fully one way or another.
>>>    
>>>
>>
>>Don''t get me started on sunfreeware....
>>
>>  
>>
>>>Then with Sol10 when they bundled a real gnu style dev env I found
that
>>>due to the compiler/linker mismatch issues if I tried to just add 
>>>packages in from blastwave or sunfreeware I would get funky linking 
>>>errors trying to build certain software bundles that would rely on a
gcc
>>>linked with gnu gld.
>>>    
>>>
>>
>>I don''t know anyone who builds anything using gcc with gnu gld
on Solaris.
>>It is well known that gnu ld and Solaris don''t get along, and
it''s one of the
>>reasons that blastwave stuff is linked using the standard solaris
linker.
>>
>>Sounds to me like you''re having LD_LIBRARY_PATH issues, or
you''re
>>not properly setting library path values with -L/-R.
>>
>>  
>>
>>>So starting with Sol10 I found if you compile everything natively
using
>>>their bundled dev environment, then everything actually works w/o
using
>>>a single Blastwave or Sunfreeware package. 
>>>    
>>>
>>
>>Peachy.  There are instructions on the opensolaris qemu project page on
>>how to build libSDL yourself.
>>
>>  
>>
>>>So right now all my Solaris 10 environments are all running the
latest
>>>openssl, openssh, openldap, kerb5, apache, apache apr, apache
apr-util,
>>>Berk DB, syslog-ng, mysql, php, etc, etc, all compiled 64 bit yet
using
>>>all the original Sol10 dev environment and base libs. Everything
works
>>>great!
>>>    
>>>
>>
>>Congrats.  Glad you have time to do so. Oh. of course.  You''re
at university.
>>Those of us with real jobs don''t have time to dedicate to
building all parts
>>of a system, just so we can be sure that it''s built to our
specifications, or
>>we''re on the bleeding edge.  My idea of bleeding edge these
days is
>>QEMU CVS and Wine, just to make sure it keeps working. The rest of it
>>I''d rather rely on stock bog solaris or blastwave.
>>
>>Sorry if I''m being a bit cynical, but when you get out in the
real world,
>>don''t expect your boss to give you buckets of time to build out
an entire
>>environment when it''s already available.
>>
>>  
>>
>>>So as soon as someone says "oh you just need this one Blastwave
package
>>>. . ." I then cringe ;-) cuz I know more than likely it will be
more
>>>than just one package. I''ll also no longer have my complete
>>>"Blastwave/Sunfreeware" free environment. For security
reasons I really
>>>prefer to use binaries that I natively compile myself.
>>>    
>>>
>>
>>Go for it.  As I mentioned earlier, the how-to compile libSDL is on the
project
>>page.
>>
>>  
>>
>>>I''ll see if I can compile the latest libSDL myself first
using my
>>>standard dev environment before I decide if I have the time to
proceed
>>>further.
>>>
>>>I only asked for the binary SPARC QEMU cuz it seemed you guys did
such a
>>>great job with the x86 version which was literally plug-n-play I
figured
>>>I''d be lazy and see if there was a binary dist . . ;-)
>>>    
>>>
>>
>>Martin did some binary distrobutions, but I don''t.  There are
too many OS rev
>>issues, and I think it''s better for the community to be able to
build their own
>>code.  If something breaks in the compilation model, I can go fix it in
the source
>>and be done.  I really don''t want to play tech support for a
binary distrobution
>>model.  There are far too many versions that have to built now that
kqemu is
>>supported from Solaris 8 to current, because each version has
it''s specific
>>kqemu module, and it''s specific hooks into it....
>>
>>The tarball is almost to the point of typing ./configure; gmake; gmake
install
>>(though it''s better to define a target destination, and which
targets you want
>>to build on).  Every special case I suspect has been covered, though I
guess
>>I may be surprised when I try again on my Solaris 9/x86 box...
>>
>>Besides, if you''re so good at compiling all that other stuff,
QEMU and libSDL
>>should be a no-brainer... :-)
>>
>>  
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>qemu-discuss mailing list
>qemu-discuss at opensolaris.org
>http://mail.opensolaris.org/mailman/listinfo/qemu-discuss
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/qemu-discuss/attachments/20071212/53e4bce9/attachment.html>

On Tue 12/11/07 at 12:37 PM, briglia at stanford.edu
wrote:
> Hey Ben,
> 
> Does the SPARC port really work? I thought I have seen mixed comments on 
> this?
> 
> I would love to be able to run QEMU on SPARC and emulate x86 Operating 
> Systems. In fact right now I have an application I want to evaluate that 
> is native to Ubuntu Linux (or however it is spelled) and at first 
> thought I figured I would try to run it on SPARC using BrandZ yet it 
> looks like the SPARC/BrandZ port is not mature enough yet.
It''s not a question of maturity.  There is no intention to support x86
Linux applications on SPARC using BrandZ.

Nils

My bad, I musta got the details mixed up about BrandZ on Sparc . . .

I''m still psyched to play with BrandZ, I just don''t have Sol
x86
anywhere yet except my laptop . . .

T.


Nils Nieuwejaar wrote:
>On Tue 12/11/07 at 12:37 PM, briglia at stanford.edu wrote:
>  
>
>>Hey Ben,
>>
>>Does the SPARC port really work? I thought I have seen mixed comments on
>>this?
>>
>>I would love to be able to run QEMU on SPARC and emulate x86 Operating 
>>Systems. In fact right now I have an application I want to evaluate that
>>is native to Ubuntu Linux (or however it is spelled) and at first 
>>thought I figured I would try to run it on SPARC using BrandZ yet it 
>>looks like the SPARC/BrandZ port is not mature enough yet.
>>    
>>
>
>It''s not a question of maturity.  There is no intention to support
x86
>Linux applications on SPARC using BrandZ.
>
>Nils
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/qemu-discuss/attachments/20071212/5a62aff1/attachment.html>

---- "Thomas D. Briglia" <briglia at stanford.edu> wrote:
> 
> Nice work with SDL, it compiled no problem, and I did not even have to 
> read the README! ;-)
Since you''re on Solaris 10, there is one dependency that I documented
last night which is for gnu tsl (transport security layer) which requires
pkg-config.  

I compiled it up on my Solaris 9/X86 box, but had to do a pkg-get -i gnutls
and pkg-get -i pkgconfig, but it all compiled right up.
> Actually first time it crapped out for I do not have audio enabled on my 
> servers yet as soon as I deactivated audio in the configuration phase it 
> compiled 64 bit no prob w/o a single Blastwave package, totally native 
> Solaris dev env! ;-)
Audio on a server is not something you''d expect to see  :-)
> My normal dev env looks like:
> 
>
PATH=/usr/sfw/bin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/usr/local/apr/bin:/usr/ucb:/usr/local/ldapcsdk-6.02/bin
> LDFLAGS=-m64 -L/usr/local/ldapcsdk-6.02/lib -L/usr/local/ssl/lib 
> -L/usr/local/lib/sasl2 -L/usr/local/lib
If you don''t want to have any problems, I''d suggest adding -R
flags for
all the -L flags you have.
> CPPFLAGS=-m64 -I/usr/local/ldapcsdk-6.02/include 
> -I/usr/local/ssl/include -I/usr/local/include/gssapi 
> -I/usr/local/include/sasl2

Well, QEMU configure overrides the CFLAGS and CPPFLAGS
to make sure that it gets the flags it expects.

I''m pretty sure

LD_LIBRARY_PATH=/usr/local/ldapcsdk-6.02/lib:/usr/lib/sasl2:/usr/local/BerkeleyDB.4.6/lib:/usr/local/ssl/lib:/usr/local/lib/sparcv9:/usr/sfw/lib/sparcv9:/usr/lib/sparcv9:/usr/local/lib:/usr/sfw/lib:/usr/lib:/usr/local/apr/lib
>
LD_LIBRARY_PATH_64=/usr/local/ldapcsdk-6.02/lib:/usr/lib/sasl2:/usr/local/BerkeleyDB.4.6/lib:/usr/local/ssl/lib:/usr/local/lib/sparcv9:/usr/sfw/lib/sparcv9:/usr/lib/sparcv9:/usr/local/apr/lib:/usr/local/lib
Dump LD_LIBRARY_PATH.  See above about -R flags (this adds runtime lookups
for the libraries so you don''t have to carry around a LD_LIBRARY_PATH).

see this http://xahlee.org/UnixResource_dir/_/ldpath.html for an explanatation.
> CFLAGS=-mcpu=v9 -m64 -O
> LDSHARED=gcc -G -mcpu=v9 -m64
> CXXFLAGS=-m64
> CC=gcc -m64
> CXX=g++ -m64
> SASL_PATH=/usr/lib/sasl2
>
PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/sfw/lib/pkgconfig
> 
> Later on I will compile QEMU. If it goes as smoothe as SDL, then a 
> double Kudos to you and all the other developers!
If you''re on Solaris 10, it should just build.  

If you''re going to use the VNC features of QEMU, then you''ll
want to also build
out GNU tls, opencdk, pgp and libpgp_error to enforce better security for the
VNC passwords that get pushed across the network.

Ben

Thx for the tips!

I''ll admit I have tried the "-R" stuff in the past yet things
did not
work out as I expected/understood they should so I sort of gave up on 
using that flag. From what I have read though it should have solved some 
of the relocation errors I have received at times during linking yet 
maybe I was not using it correctly??

Also to disclaim, I have an SA/DBA/Security background and I am not a 
developer per se so I''ll admit right off that when it comes to 
compiling/building code I am more of a trial & error hacker 
(non-security definition) than a true developer like you folks are . . ;-)

I''ll holler if I get stumped with the gnu tsl stuff yet I think I might
already have that stuff on my dev system, can''t remember right now . .
.

Thx!

T.

Ben Taylor wrote:
>---- "Thomas D. Briglia" <briglia at stanford.edu> wrote: 
>  
>
>>Nice work with SDL, it compiled no problem, and I did not even have to 
>>read the README! ;-)
>>    
>>
>
>Since you''re on Solaris 10, there is one dependency that I
documented
>last night which is for gnu tsl (transport security layer) which requires
>pkg-config.  
>
>I compiled it up on my Solaris 9/X86 box, but had to do a pkg-get -i gnutls
>and pkg-get -i pkgconfig, but it all compiled right up.
>
>  
>
>>Actually first time it crapped out for I do not have audio enabled on my
>>servers yet as soon as I deactivated audio in the configuration phase it
>>compiled 64 bit no prob w/o a single Blastwave package, totally native 
>>Solaris dev env! ;-)
>>    
>>
>
>Audio on a server is not something you''d expect to see  :-)
>
>  
>
>>My normal dev env looks like:
>>
>>PATH=/usr/sfw/bin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/usr/local/apr/bin:/usr/ucb:/usr/local/ldapcsdk-6.02/bin
>>LDFLAGS=-m64 -L/usr/local/ldapcsdk-6.02/lib -L/usr/local/ssl/lib 
>>-L/usr/local/lib/sasl2 -L/usr/local/lib
>>    
>>
>
>If you don''t want to have any problems, I''d suggest adding
-R flags for
>all the -L flags you have.
>
>  
>
>>CPPFLAGS=-m64 -I/usr/local/ldapcsdk-6.02/include 
>>-I/usr/local/ssl/include -I/usr/local/include/gssapi 
>>-I/usr/local/include/sasl2
>>    
>>
>
>
>Well, QEMU configure overrides the CFLAGS and CPPFLAGS
>to make sure that it gets the flags it expects.
>
>I''m pretty sure
>
>LD_LIBRARY_PATH=/usr/local/ldapcsdk-6.02/lib:/usr/lib/sasl2:/usr/local/BerkeleyDB.4.6/lib:/usr/local/ssl/lib:/usr/local/lib/sparcv9:/usr/sfw/lib/sparcv9:/usr/lib/sparcv9:/usr/local/lib:/usr/sfw/lib:/usr/lib:/usr/local/apr/lib
>  
>
>>LD_LIBRARY_PATH_64=/usr/local/ldapcsdk-6.02/lib:/usr/lib/sasl2:/usr/local/BerkeleyDB.4.6/lib:/usr/local/ssl/lib:/usr/local/lib/sparcv9:/usr/sfw/lib/sparcv9:/usr/lib/sparcv9:/usr/local/apr/lib:/usr/local/lib
>>    
>>
>
>Dump LD_LIBRARY_PATH.  See above about -R flags (this adds runtime lookups
>for the libraries so you don''t have to carry around a
LD_LIBRARY_PATH).
>
>see this http://xahlee.org/UnixResource_dir/_/ldpath.html for an
explanatation.
>
>  
>
>>CFLAGS=-mcpu=v9 -m64 -O
>>LDSHARED=gcc -G -mcpu=v9 -m64
>>CXXFLAGS=-m64
>>CC=gcc -m64
>>CXX=g++ -m64
>>SASL_PATH=/usr/lib/sasl2
>>PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/sfw/lib/pkgconfig
>>
>>Later on I will compile QEMU. If it goes as smoothe as SDL, then a 
>>double Kudos to you and all the other developers!
>>    
>>
>
>If you''re on Solaris 10, it should just build.  
>
>If you''re going to use the VNC features of QEMU, then
you''ll want to also build
>out GNU tls, opencdk, pgp and libpgp_error to enforce better security for
the
>VNC passwords that get pushed across the network.
>
>Ben
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/qemu-discuss/attachments/20071212/f147497f/attachment.html>

Hey Ben,

OK giving the latest build a try on Sol 10 SPARC and here are some 
initial comments/observations:

1) So although the README says:

For Solaris 10 Sparc and X86, use /usr/sfw/bin/gcc


When you try to use that compiler you get:

 ./configure

Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu correctly.

please get gcc-3.4.3 or later, from www.blastwave.org using pkg-get -i gcc3 or
get the latest patch from SunSolve for gcc


The compiler in /usr/sfw/bin is 3.4.3 though:

 /usr/sfw/bin/gcc -dumpversion

3.4.3


So I guess my comment here is that although the README says to use
/usr/sfw/bin/gcc, the configure script does not seem to like that 
version even though gcc actually reports it is the correct version.

Anyway just to make sure I follow the error instructions from configure 
I went to sunsolve and grabbed the only Sol 10 gcc patch I could find 
"123647-01 SUNWgccruntime" installed it yet still get the same error.


2) So getting past the compiler version issue if I use 
--disable-gcc-check I now see that there is no support for SPARC 64 bit? 
It was unclear in the README and just says:

64-bit sparc has not been tested and is unlikely to work, due to the lack of
64-bit libraries for X and libSDL


Well I did successfully compile libSDL 64 bit so that cannot be the 
problem, exactly which "64 bit X libraries" are being referred to in
the
README? I am guessing there is not even a SPARC 64 target though based 
on the "Target List" in the configure output:

./configure --disable-gcc-check --install=/usr/ucb/install --sparc_cpu=v9

Install prefix    /usr/local

BIOS directory    /usr/local/share/qemu

binary directory  /usr/local/bin

Manual directory  /usr/local/share/man

ELF interp prefix /usr/gnemul/qemu-%M

Source path       /opt/local/qemu

C compiler        gcc

Host C compiler   gcc

make              gmake

install           /usr/ucb/install

host CPU          sparc64

host big endian   yes

target list       i386-softmmu sparc-softmmu x86_64-softmmu mips-softmmu
mipsel-softmmu mips64-softmmu mips64el-softmmu arm-softmmu ppc-softmmu
ppcemb-softmmu ppc64-softmmu m68k-softmmu sh4-softmmu sh4eb-softmmu cris-softmmu

gprof enabled     no

profiler          no

static build      no

-Werror enabled   no

SDL support       no

mingw32 support   no

Adlib support     no

CoreAudio support no

ALSA support      no

DSound support    no

FMOD support      no

OSS support       no

VNC TLS support   no

Target Sparc Arch v9

kqemu support     no

Documentation     no

The error log from compiling the libSDL test is:

ld: fatal: file /usr/local/lib/libSDL.so: wrong ELF class: ELFCLASS64


So is there anything in the configure script or the "target-sparc" 
directory I can tweak to try to build 64 bit or should I just go back 
and recompile libSDL 32 bit and just settle for a 32 bit qemu SPARC build?

I am trying to keep everything I build on my systems 64 bit just for 
uniformity though more than anything.

Thx!

Tom


Ben Taylor wrote:
>---- "Thomas D. Briglia" <briglia at stanford.edu> wrote: 
>  
>
>>Nice work with SDL, it compiled no problem, and I did not even have to 
>>read the README! ;-)
>>    
>>
>
>Since you''re on Solaris 10, there is one dependency that I
documented
>last night which is for gnu tsl (transport security layer) which requires
>pkg-config.  
>
>I compiled it up on my Solaris 9/X86 box, but had to do a pkg-get -i gnutls
>and pkg-get -i pkgconfig, but it all compiled right up.
>
>  
>
>>Actually first time it crapped out for I do not have audio enabled on my
>>servers yet as soon as I deactivated audio in the configuration phase it
>>compiled 64 bit no prob w/o a single Blastwave package, totally native 
>>Solaris dev env! ;-)
>>    
>>
>
>Audio on a server is not something you''d expect to see  :-)
>
>  
>
>>My normal dev env looks like:
>>
>>PATH=/usr/sfw/bin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/usr/local/apr/bin:/usr/ucb:/usr/local/ldapcsdk-6.02/bin
>>LDFLAGS=-m64 -L/usr/local/ldapcsdk-6.02/lib -L/usr/local/ssl/lib 
>>-L/usr/local/lib/sasl2 -L/usr/local/lib
>>    
>>
>
>If you don''t want to have any problems, I''d suggest adding
-R flags for
>all the -L flags you have.
>
>  
>
>>CPPFLAGS=-m64 -I/usr/local/ldapcsdk-6.02/include 
>>-I/usr/local/ssl/include -I/usr/local/include/gssapi 
>>-I/usr/local/include/sasl2
>>    
>>
>
>
>Well, QEMU configure overrides the CFLAGS and CPPFLAGS
>to make sure that it gets the flags it expects.
>
>I''m pretty sure
>
>LD_LIBRARY_PATH=/usr/local/ldapcsdk-6.02/lib:/usr/lib/sasl2:/usr/local/BerkeleyDB.4.6/lib:/usr/local/ssl/lib:/usr/local/lib/sparcv9:/usr/sfw/lib/sparcv9:/usr/lib/sparcv9:/usr/local/lib:/usr/sfw/lib:/usr/lib:/usr/local/apr/lib
>  
>
>>LD_LIBRARY_PATH_64=/usr/local/ldapcsdk-6.02/lib:/usr/lib/sasl2:/usr/local/BerkeleyDB.4.6/lib:/usr/local/ssl/lib:/usr/local/lib/sparcv9:/usr/sfw/lib/sparcv9:/usr/lib/sparcv9:/usr/local/apr/lib:/usr/local/lib
>>    
>>
>
>Dump LD_LIBRARY_PATH.  See above about -R flags (this adds runtime lookups
>for the libraries so you don''t have to carry around a
LD_LIBRARY_PATH).
>
>see this http://xahlee.org/UnixResource_dir/_/ldpath.html for an
explanatation.
>
>  
>
>>CFLAGS=-mcpu=v9 -m64 -O
>>LDSHARED=gcc -G -mcpu=v9 -m64
>>CXXFLAGS=-m64
>>CC=gcc -m64
>>CXX=g++ -m64
>>SASL_PATH=/usr/lib/sasl2
>>PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/sfw/lib/pkgconfig
>>
>>Later on I will compile QEMU. If it goes as smoothe as SDL, then a 
>>double Kudos to you and all the other developers!
>>    
>>
>
>If you''re on Solaris 10, it should just build.  
>
>If you''re going to use the VNC features of QEMU, then
you''ll want to also build
>out GNU tls, opencdk, pgp and libpgp_error to enforce better security for
the
>VNC passwords that get pushed across the network.
>
>Ben
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/qemu-discuss/attachments/20071212/40811def/attachment.html>

---- "Thomas D. Briglia" <briglia at stanford.edu> wrote:
> Hey Ben,
> 
> OK giving the latest build a try on Sol 10 SPARC and here are some 
> initial comments/observations:
> 
> 1) So although the README says:
> 
> For Solaris 10 Sparc and X86, use /usr/sfw/bin/gcc
> 
> 
> When you try to use that compiler you get:
> 
>  ./configure
> 
> Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu correctly.
> 
> please get gcc-3.4.3 or later, from www.blastwave.org using pkg-get -i gcc3
or get the latest patch from SunSolve for gcc
configure with --disable-gcc-check

We were never able to put our finger on why /usr/sfw/bin/gcc didn''t
work right, but it''s working right now.  I''ll make sure I
update the webpages
and the Solaris.README in the tarball.
> The compiler in /usr/sfw/bin is 3.4.3 though:
> 
>  /usr/sfw/bin/gcc -dumpversion
> 
> 3.4.3
> 
> 
> So I guess my comment here is that although the README says to use
> /usr/sfw/bin/gcc, the configure script does not seem to like that 
> version even though gcc actually reports it is the correct version.
Sorry about that.  Let me think about removing that check.  In the
mean time, you get around it by --disable-gcc-check, then it should
work.
> Anyway just to make sure I follow the error instructions from configure 
> I went to sunsolve and grabbed the only Sol 10 gcc patch I could find 
> "123647-01 SUNWgccruntime" installed it yet still get the same
error.
Ok.  The problem we experienced probably 2 years ago we weren''t able
to track down.  For a long time, we could only use blastwaves gcc 3.4.x,
but at some point, either the qemu code changed and /usr/sfw/bin/gcc
didn''t error anymore, or the gcc patch actually fixed something.
> 2) So getting past the compiler version issue if I use 
> --disable-gcc-check I now see that there is no support for SPARC 64 bit? 
> It was unclear in the README and just says:
Good, you found the option.
> 64-bit sparc has not been tested and is unlikely to work, due to the lack
of 64-bit libraries for X and libSDL
without 64-bit X libraries, it''s unlikely that QEMU will compile 64-bit
on
sparc Solaris 10  if you enable libSDL.  I never tested without libSDL, 
so it may compile, but I can tell you that my attempts to get a 64-bit 
compile working on sparc ended up with some pretty ugly errors that 
I was unable to debug, and I was dissuaded from persusing it by one
of the other QEMU project leaders...
> Well I did successfully compile libSDL 64 bit so that cannot be the 
> problem, exactly which "64 bit X libraries" are being referred to
in the
> README? I am guessing there is not even a SPARC 64 target though based 
> on the "Target List" in the configure output:
libSDL talks through the X-libraries, specifically  libX11.so and libXext.so, so
there is no chance that a 64-bit build will ever work, at least graphically, on
Solaris 10 Sparc.  Solaris Express has 64-bit X libraries, so there is a
possibilty
that this could work, but I gave up on trying to make 64-bit work on sparc after
the other errors I ran into.
> ./configure --disable-gcc-check --install=/usr/ucb/install --sparc_cpu=v9
> 
> Install prefix    /usr/local
> BIOS directory    /usr/local/share/qemu
> binary directory  /usr/local/bin
> Manual directory  /usr/local/share/man
> ELF interp prefix /usr/gnemul/qemu-%M
> Source path       /opt/local/qemu
> C compiler        gcc
> Host C compiler   gcc
> make              gmake
> install           /usr/ucb/install
> host CPU          sparc64
> host big endian   yes
> target list       i386-softmmu sparc-softmmu x86_64-softmmu mips-softmmu
mipsel-softmmu mips64-softmmu mips64el-softmmu arm-softmmu ppc-softmmu
ppcemb-softmmu ppc64-softmmu m68k-softmmu sh4-softmmu sh4eb-softmmu cris-softmmu
> gprof enabled     no
> profiler          no
> static build      no
> -Werror enabled   no
> SDL support       no
> mingw32 support   no
> Adlib support     no
> CoreAudio support no
> ALSA support      no
> DSound support    no
> FMOD support      no
> OSS support       no
> VNC TLS support   no
> Target Sparc Arch v9
> kqemu support     no
> Documentation     no
> The error log from compiling the libSDL test is:
the sparc_cpu code was put in, in the hopes that other project leads
would follow through with adding some more code to support
the different processor types.  That hasn''t happened, so  I
wouldn''t
recommend using it for the time being.

Again, I''ll try to get this documented.
> 
> ld: fatal: file /usr/local/lib/libSDL.so: wrong ELF class: ELFCLASS64
> 
> 
> So is there anything in the configure script or the
"target-sparc"
> directory I can tweak to try to build 64 bit or should I just go back 
> and recompile libSDL 32 bit and just settle for a 32 bit qemu SPARC build?
For Solaris 10, you have to settle for a 32-bit build.  If you figure out how
to get into your VM''s without libSDL, you might be able to build a
64-bit
version.
> I am trying to keep everything I build on my systems 64 bit just for 
> uniformity though more than anything.
Well, if you put enough work into QEMU, you might be able to build a 64-bit
version without libSDL support.  But no work has been put into 64-bit on
Solaris because it was missing 64-bit X-libraries needed for libSDL.


Ben

Ben Taylor wrote:

Hi,
>>Building QEMU is now *very* easy.
Mmm, compiling qemu on snv78 does not work :

test/qemu -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -I/export/var/develop/qemu/test/qemu/fpu  
-DHAS_AUDIO -I/export/var/develop/qemu/test/qemu/slirp -c -o op.o 
/export/var/develop/qemu/test/qemu/target-mips/op.c
/export/var/develop/qemu/test/qemu/target-mips/op.c: In function 
`op_goto_tb0'':
/export/var/develop/qemu/test/qemu/target-mips/op.c:916: warning: cast 
to pointer from integer of different size
/export/var/develop/qemu/test/qemu/target-mips/op.c: In function 
`op_goto_tb1'':
/export/var/develop/qemu/test/qemu/target-mips/op.c:922: warning: cast 
to pointer from integer of different size
/export/var/develop/qemu/test/qemu/target-mips/op_mem.c: In function 
`op_lwl_raw'':
/export/var/develop/qemu/test/qemu/target-mips/op_mem.c:110: internal 
compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
gmake[1]: *** [op.o] Error 1
gmake[1]: Leaving directory 
`/export/var/develop/qemu/test/qemu/mips-softmmu''
gmake: *** [subdir-mips-softmmu] Error 2

Environment

bash-3.2# uname -a
SunOS dhcppc2 5.11 snv_78 i86pc i386 i86xpv

bash-3.2# isainfo -x
amd64: ahf sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov cx8 
tsc fpu
i386: ahf sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov cx8 
tsc fpu

The source code used is:

bash-3.2# ls -l ../..
total 110098
-rw-r--r--   1 root     root     50980864 Dec 21 16:43 dsl-4.0.iso
-rw-r--r--   1 root     root      167748 Dec 21 16:32 
kqemu_1.0.3pre11-20070520.tar.bz2
-rw-r--r--   1 root     root     2304413 Dec 21 16:32 
qemu-src-CVSdrop-12112007-pluspatches.tar.bz2
-rw-r--r--   1 root     root     2829456 Dec 21 16:32 SDL-1.2.12.tar.gz
drwxr-xr-x   5 root     root         512 Dec 21 16:34 test

bash-3.2# gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure 
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as 
--with-ld=/usr/ccs/bin/ld --without-gnu-ld 
--enable-languages=c,c++,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)

Tried it on a Ferrari with fresh installed Solaris snv78 without any changes

regards

Bernd


> ---- Bernd Schemmer <Bernd.Schemmer at gmx.de> wrote: 
>   
>> Ben,
>>
>>  >>I''ve just uploaded a current CVS tarball of the
QEMU-0.9.0 code from
>> today,
>>
>> Only changes to Qemu? Or also to kqemu?
>>     
>
> Kqemu hasn''t changed in 6 months.  Most of the changes for Solaris
have
> to do with configure/Makefile and occaionally the odd source file.
>
>   
>> The last time I tried Qemu with kqemu in a Xen Dom0 it crashed the 
>> system if kqemu was enabled
>>     
>
> Well, I have been meaning to try this, and hopefully will be able to spend
> some time with it before the new year.
>
>   
>> (tested with SUNWqemu 0.9.0__cvs20070220tue , the kqemu version used
for
>> the tests was 
>> kqemu-osol-1.3.0pre9-v0.2.tar.kqemu-osol-1.3.0pre9-v0.2.tar.gz)
>>     
>
> That is a very old version of QEMU and kqemu.  That version of kqemu will
> only run on Solaris Express.  The source version in the downloads page
> supports 8-current Solaris X86 i386, and Solaris 10-current for x86-64.
>
> Building QEMU is now *very* easy.  Really.  All you need is libSDL, a
working
> gcc compiler (and this is documented in the tarball, and on the qemu
project
> page),  zlib, and gnutls.  Damn.  gnutls is part of Solaris 10, but I
haven''t tested
> it on 9/x86.  Guess I gotta fire up the Dual Celeron 550... :-)
>
> Ben
>
>   

-- 
Bernd Schemmer, Frankfurt am Main, Germany
http://home.arcor.de/bnsmb/index.html

M s temprano que tarde el mundo cambiar .
                        Fidel Castro

---- Bernd Schemmer <Bernd.Schemmer at gmx.de> wrote:
> Ben Taylor wrote:
> 
> Hi,
> 
> >>Building QEMU is now *very* easy.
> 
> Mmm, compiling qemu on snv78 does not work :
> 
> test/qemu -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -I/export/var/develop/qemu/test/qemu/fpu  
> -DHAS_AUDIO -I/export/var/develop/qemu/test/qemu/slirp -c -o op.o 
> /export/var/develop/qemu/test/qemu/target-mips/op.c
> /export/var/develop/qemu/test/qemu/target-mips/op.c: In function 
> `op_goto_tb0'':
> /export/var/develop/qemu/test/qemu/target-mips/op.c:916: warning: cast 
> to pointer from integer of different size
> /export/var/develop/qemu/test/qemu/target-mips/op.c: In function 
> `op_goto_tb1'':
> /export/var/develop/qemu/test/qemu/target-mips/op.c:922: warning: cast 
> to pointer from integer of different size
> /export/var/develop/qemu/test/qemu/target-mips/op_mem.c: In function 
> `op_lwl_raw'':
> /export/var/develop/qemu/test/qemu/target-mips/op_mem.c:110: internal 
> compiler error: Segmentation Fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> gmake[1]: *** [op.o] Error 1
> gmake[1]: Leaving directory 
> `/export/var/develop/qemu/test/qemu/mips-softmmu''
> gmake: *** [subdir-mips-softmmu] Error 2
yes, I found this a couple of days ago, but haven''t been able
to do any more research on it.  This is a 64-bit problem
that happens on Nevada, but surprisingly enough, not
on Solaris 10U2.

I need to get it setup so that I can create the assembler
file so I can file a bug report with Sun.

In the meantime, if you don''t need mips, remove it
from the target-list, and all should work.

Ben