[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
disabled.
Your hunch was correct. Once I got gcc and glib updated, those issues
disappeared.
-----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
testing.
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...
thanks
-- PMM