[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] EXT :Re: Compiling qemu 2.8 on Solaris 10

From: Wu, Michael Y [US] (MS)
Subject: Re: [Qemu-discuss] EXT :Re: Compiling qemu 2.8 on Solaris 10
Date: Tue, 28 Mar 2017 19:36:38 +0000

Hi Peter,

Thanks for the response. I was able to successfully build QEMU on Solaris 10. 
Some minor alterations had to be made to the source code and some features 

Your hunch was correct. Once I got gcc and glib updated, those issues 

-----Original Message-----
From: Peter Maydell [mailto:address@hidden 
Sent: Tuesday, March 14, 2017 11:17 AM
To: Wu, Michael Y [US] (MS)
Cc: address@hidden
Subject: EXT :Re: [Qemu-discuss] Compiling qemu 2.8 on Solaris 10

On 14 March 2017 at 17:47, Wu, Michael Y [US] (MS) <address@hidden> wrote:
> I am trying to compile qemu 2.8 on solaris 10 (ultrasparc).
> The most success I’ve had with compiling is using the configure 
> command
> below:
> ../qemu/configure --cc=/usr/local/gcc-4.2.1/gcc/bin/gcc
> --python=/opt/csw/bin/python2.7 --make=/usr/local/bin/make 
> --target-list=ppc-softmmu --disable-tools --disable-gcrypt 
> --disable-stack-protector

> I disabled several features to get around some compilation issues.  
> The error I am receiving now is:
>   LINK    ppc-softmmu/qemu-system-ppc
> Undefined                       first referenced
> symbol                             in file
> __sync_fetch_and_or_1               cputlb.o

> This has gotten me stumped. I tried so many things to fix this but 
> nothing successful. I figured that it might be my gcc version (4.2.1) 
> so I went ahead and created a simple C file using the built in __sync_fetch 
> functions.
> Compiling the test file was no issue at all. I was able to build Any 
> suggestions would be great!

That's a bit odd, but it may be that your version of gcc can do some of the 
variants of the sync_fetch atomics inline but not all of them (it's probably 
trying to call out-of-line functions in libatomic, which we don't link against 
because in theory we shouldn't need them).

I would suggest trying with a more recent gcc -- 4.2 is the absolute oldest gcc 
we support, 4.2.1 is a decade old, and the atomics support only came in in 4.2, 
so bugs would not be all that surprising.

Your other problem is that Solaris host support is pretty much unmaintained and 
untested upstream -- we have no Solaris system that we can use for even compile 
We'll probably drop Solaris host support entirely in a release or two unless 
somebody cares enough to provide us with a testing machine and work with 
upstream on testing and support...

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]