[Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?

[Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?

[Rui Carmo]

Hello, 

I've been trying to get a working build of QEMU 1.0 (or HEAD) that would build or run on Mac OS X Lion without segfaulting or spinlocking, and so far the only way I've been able to build it _and_ run it is by using gcc-4.2 instead of LLVM. Clang doesn't work either (it doesn't support global register variables).

I was wondering who might be looking into that, since I couldn't figure out where this kind of issue would be classified in the MAINTAINERS file I've only found Andreas (hi!) listed where it concerns Cocoa, but this is not a Cocoa issue.

For the record, the way I got it to build was patching fpu/softfloat.h (see below, I think this has been submitted as a formal patch by someone else, but can't find it either) and setting --cc=gcc-4.2 --host-cc=gcc-4.2.

The issue with that is that "plain" GCC isn't bundled with Xcode anymore (even though I have it on all the machines I tried this, it was apparently removed around Xcode 4.1 or thereabouts and my upgrades preserved it), so I'd like to get in touch with someone that might be able to address the LLVM issue.

Regards,

R.

http://the.taoofmac.com

--

diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index 07c2929..229d834 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -57,7 +57,7 @@ typedef uint8_t flag;
 typedef uint8_t uint8;
 typedef int8_t int8;
 #ifndef _AIX
-typedef int uint16;
+typedef uint16_t uint16;
-typedef int int16;
+typedef int16_t int16;
 #endif
 typedef unsigned int uint32;

(remember, this is not a formal patch)

[Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?

[Rui Carmo]

Hello, 

I posted this to the list a couple of days ago but I still don't see it in the archives, so here goes again...

I've been trying to get a working build of QEMU 1.0 (or HEAD) that would build or run on Mac OS X Lion without segfaulting or spinlocking, and so far the only way I've been able to build it _and_ run it is by using gcc-4.2 instead of LLVM. Clang doesn't work either (it doesn't support global register variables).

I was wondering who might be looking into that, since I couldn't figure out where this kind of issue would be classified in the MAINTAINERS file I've only found Andreas (hi!) listed where it concerns Cocoa, but this is not a Cocoa issue.

For the record, the way I got it to build was patching fpu/softfloat.h (see below, I think this has been submitted as a formal patch by someone else, but can't find it either) and setting --cc=gcc-4.2 --host-cc=gcc-4.2.

The issue with that is that "plain" GCC isn't bundled with Xcode anymore (even though I have it on all the machines I tried this, it was apparently removed around Xcode 4.1 or thereabouts and my upgrades preserved it), so I'd like to get in touch with someone that might be able to address the LLVM issue.

Regards,

R.

http://the.taoofmac.com

--

diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index 07c2929..229d834 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -57,7 +57,7 @@ typedef uint8_t flag;
typedef uint8_t uint8;
typedef int8_t int8;
#ifndef _AIX
-typedef int uint16;
+typedef uint16_t uint16;
-typedef int int16;
+typedef int16_t int16;
#endif
typedef unsigned int uint32;

(remember, this is not a formal patch)

Re: [Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?

[Peter Maydell]

On 10 January 2012 11:18, Rui Carmo <rui.carmo@gmail.com> wrote:
> For the record, the way I got it to build was patching fpu/softfloat.h (see below, I think this has been submitted as a formal patch by someone else, but can't find it either) and setting --cc=gcc-4.2 --host-cc=gcc-4.2.

[uint16/int16 typename clashes]

This is still waiting for somebody to get round to doing a basic
noddy FPU-intensive benchmark of (eg) an ARM target on a Linux
host to find out whether int16_t vs int_fast16_t makes any
difference at all to performance. (My suspicion is 'no'.)

-- PMM

Re: [Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?

[Rui Carmo]

On Jan 11, 2012, at 19:24 , Peter Maydell wrote:

> This is still waiting for somebody to get round to doing a basic
> noddy FPU-intensive benchmark of (eg) an ARM target on a Linux
> host to find out whether int16_t vs int_fast16_t makes any
> difference at all to performance. (My suspicion is 'no'.)

Quite so - I've since exchanged a couple of messages with Andreas and ascertained that. 

But QEMU not running properly when compiled with LLVM is the real problem here, since that means people won't be able to build it unless they have an outdated compiler around (fresh installs of Xcode don't bundle "normal" gcc anymore).

I'm starting to think I'm the only person trying to build it with a current Mac toolchain...

R.