master on Xcode 4 / OS X Lion

82 views
Skip to first unread message

Al Sutton

unread,
Dec 17, 2011, 7:42:54 AM12/17/11
to android-...@googlegroups.com
I've had a bit of time to look at the build system and found what looks to be the cause of the first compilation problem when qemu is being compiled under OS X 10.7 and XCode 4.

The libSDL files are copied from the prebuilt directory at prebuilt/darwin-x86/sdl/lib/ and then ranlib is run against them after the copy and appears to strip the architecture information which then leads to the linking error. To show this you can compile up the master branch until the libSDL error, then run;

cp prebuilt/darwin-x86/sdl/lib/libSDL* out/host/darwin-x86/obj/STATIC_LIBRARIES/libSDL_intermediates/

then start make again and you get a similar error for the next library on (emulator-libelff.a).

An initial fix might be to stop ranlib running after the copy, which is pretty simple to do with the following patch in the build project;

diff --git a/core/combo/HOST_darwin-x86.mk b/core/combo/HOST_darwin-x86.mk
index 544a29e..407c74f 100644
--- a/core/combo/HOST_darwin-x86.mk
+++ b/core/combo/HOST_darwin-x86.mk
@@ -53,7 +53,11 @@ HOST_JNILIB_SUFFIX := .jnilib

HOST_GLOBAL_CFLAGS += \
-include $(call select-android-config-h,darwin-x86)
-HOST_RUN_RANLIB_AFTER_COPYING := true
+ifneq ($(filter 10.7.%, $(build_mac_version)),)
+ HOST_RUN_RANLIB_AFTER_COPYING := false
+else
+ HOST_RUN_RANLIB_AFTER_COPYING := true
+endif
HOST_GLOBAL_ARFLAGS := cqs

HOST_CUSTOM_LD_COMMAND := true

This stops the ranlib if the compilation host is 10.7, and so solves the libSDL issue.

So what are peoples thoughts about this as a first step?

Al
--
T: @alsutton W: www.funkyandroid.com

The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.

Jean-Baptiste Queru

unread,
Dec 19, 2011, 12:08:32 PM12/19/11
to android-...@googlegroups.com
That sounds interesting. What is the anticipated effect of not running
ranlib? (size, speed?)

JBQ

> --
> You received this message because you are subscribed to the "Android Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

Evan

unread,
Dec 17, 2011, 9:03:40 PM12/17/11
to Android Building
Or maybe replace the prebuilt libSDL library with an universal one?

Al Sutton

unread,
Dec 19, 2011, 1:29:18 PM12/19/11
to android-...@googlegroups.com
As far as I can tell there's no impact on the file size, so I doubt there'd be any end impact although I wont know for sure until I've got the remaining compilation errors resolved which should make a full build possible.

Are you able to say if there are any plans to move the master emulator to a 64-build?, if so I'll focus on that rather than trying to get everything going through as 32 bit.

Al.


--
T: @alsutton W: www.funkyandroid.com

The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.

Jean-Baptiste Queru

unread,
Dec 19, 2011, 1:33:23 PM12/19/11
to android-...@googlegroups.com
As far as I know, unless there've been some recent developments in
upstream qemu, the emulator is going to remain 32-bit for now (since
it JITs ARM code into IA32 code).

JBQ

Al Sutton

unread,
Dec 19, 2011, 1:50:19 PM12/19/11
to android-...@googlegroups.com
It looks like they've qemu 1.0 has a version of tcg which can generate 64 bit code, but if it's not something that's being worked on inside Google then I'll stay with the 32 bit route because I can't see a bulk qemu update submission going down too easily :).

Al.
--
T: @alsutton W: www.funkyandroid.com

The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.

Jean-Baptiste Queru

unread,
Dec 19, 2011, 2:02:09 PM12/19/11
to android-...@googlegroups.com
Indeed, for now assuming 32-bit remains safe. I'm not aware of any
internal effort (yet) to move to 64-bit, and based on what I remember
from past merges with upstream this is going to be a major task so
32-bit-related work isn't going to go to waste.

JBQ

Reply all
Reply to author
Forward
0 new messages