Hello !
Is there any way to see what OSX version
an Universal Binary needs to run on ppc and/or i386 ?
CU
Hello Torsten,
Saturday, December 2, 2006, 4:10:21 PM, you wrote:
Is there any way to see what OSX version
an Universal Binary needs to run on ppc and/or i386 ?
For PPC, provided you compile the PPC code with gcc 3, it runs on 10.2
and later. i386 must be compiled with gcc 4 which runs on 10.4. PPC
code compiled with gcc 4 needs 10.3.9 to work.
If you want to have a UB which will work for PPC back to 10.2.x, you
must compile ppc and i386 code seperately, and glue the two
executables together with the lipo tool.
Please tell Apple how stupid this is, and demand that they make gcc 4
code work on earlier OS’s. As a result of this, and bugs in gcc 3, the
ports I have done simply require 10.3.9 or later to run.–
Best regards,
Peter mailto:@Peter_Mulholland
Hello !
For PPC, provided you compile the PPC code with gcc 3, it runs on 10.2
and later. i386 must be compiled with gcc 4 which runs on 10.4. PPC code
compiled with gcc 4 needs 10.3.9 to work.If you want to have a UB which will work for PPC back to 10.2.x, you
must compile ppc and i386 code seperately, and glue the two executables
together with the lipo tool.Please tell Apple how stupid this is, and demand that they make gcc 4
code work on earlier OS’s. As a result of this, and bugs in gcc 3, the
ports I have done simply require 10.3.9 or later to run.
It is stupid, really.
I just wanted to know
if there is any way to see not just if the binary is an UB,
but also what OSXes it needs.
For example for UBs not created by me.
CU
Hello Torsten,
Saturday, December 2, 2006, 4:43:15 PM, you wrote:
It is stupid, really.
I just wanted to know
if there is any way to see not just if the binary is an UB,
but also what OSXes it needs.
For example for UBs not created by me.
Ahh, OK.
At a rough guess, you could use otool -L. If the PPC part of the binary
links to libSystem.B.dylib, it needs 10.3.9+. If it links to
libSystem.dylib it can run on earlier systems.
You may want to verify this with a gcc3 compiled PPC binary first. I
could be wrong :)–
Best regards,
Peter mailto:@Peter_Mulholland
It is stupid, really.
I just wanted to know
if there is any way to see not just if the binary is an UB,
but also what OSXes it needs.
One way is manually splitting the binary using lipo (e.g. lipo -extract
i386 binary -output binary.i386) and then checking dependencies for each
of the files (e.g. otool -L binary.i386). Things to look out for are e.g.
libgcc_s and libstdc++, which are available from 10.3.9 onwards. It also
tells you which version of the libraries it requires.
// MartinOn Sat, 2 Dec 2006, Torsten Giebl wrote:
Hello !
At a rough guess, you could use otool -L. If the PPC part of the binary
links to libSystem.B.dylib, it needs 10.3.9+. If it links to
libSystem.dylib it can run on earlier systems.You may want to verify this with a gcc3 compiled PPC binary first. I
could be wrong
No, you are wrong. I just tested this with SDL and
used the fatbuild.sh ppc part. I am on a PPC Mac with the latest
XCode Tools and Updates :-----------------
c0a80121:/tmp/SDL-1.2/build/ppc/build/.libs wizard$ otool -L libSDL.dylib
libSDL.dylib:
/usr/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0,
current version 12.1.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
(compatibility version 1.0.0, current version 120.3.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 8.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
(compatibility version 1.0.0, current version 12.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility version 1.0.0, current version 18.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 122.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 63.0.0)
c0a80121:/tmp/SDL-1.2/build/ppc/build/.libs wizard$
I hope there is any way to do the checking.
CU
You could check the version of libSystem.B.dylib it links to (and you
don’t need to split the binary for that, otool has an ‘-arch’ option):
buia:~ cwalther$ otool -L
/Developer/SDKs/MacOSX10.2.8.sdk/usr/lib/libSystem.B.dylib
/Developer/SDKs/MacOSX10.2.8.sdk/usr/lib/libSystem.B.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 63.0.0)
/usr/lib/system/libmathCommon.A.dylib (compatibility version
1.0.0, current version 40.1.0)
buia:~ cwalther$ otool -L
/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/libSystem.B.dylib
/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/libSystem.B.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 71.1.3)
/usr/lib/system/libmathCommon.A.dylib (compatibility version
1.0.0, current version 47.1.0)
buia:~ cwalther$ otool -L
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.B.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.B.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.3)
/usr/lib/system/libmathCommon.A.dylib (compatibility version
1.0.0, current version 220.0.0)
buia:~ cwalther$ otool -L -arch ppc /Library/Frameworks/SDL.framework/SDL
/Library/Frameworks/SDL.framework/SDL:
…
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 63.0.0)
buia:~ cwalther$ otool -L -arch i386 /Library/Frameworks/SDL.framework/SDL
/Library/Frameworks/SDL.framework/SDL:
…
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.3)
But that’s probably not a sure-fire way of determining system
compatibility. I think I’ve seen binaries that ran on 10.2.8 even though
they were linked against later versions of libSystem.B.dylib.
-Christian
Anyone feel like doing this – or merely creating a 10.2-compatible
PPC build – of Tux Paint for me? ( http://www.tuxpaint.org/ )
Currently we have a Unviersal Binary, which requires 10.3.9 and later. :^(
Thanks! :)On Sat, Dec 02, 2006 at 04:30:30PM +0000, Peter Mulholland wrote:
If you want to have a UB which will work for PPC back to 10.2.x, you
must compile ppc and i386 code seperately, and glue the two
executables together with the lipo tool.
–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/
Hello !
One way is manually splitting the binary using lipo (e.g. lipo -extract
i386 binary -output binary.i386) and then checking dependencies for each of
the files (e.g. otool -L binary.i386). Things to look out for are e.g.
libgcc_s and libstdc++, which are available from 10.3.9 onwards. It also
tells you which version of the libraries it requires.
Don’t you mean binary.ppc ? As i am
interested in the ppc version.
Peter Mulholland wrote:
For PPC, provided you compile the PPC code with gcc 3, it runs on 10.2
and later. i386 must be compiled with gcc 4 which runs on 10.4. PPC
code compiled with gcc 4 needs 10.3.9 to work.If you want to have a UB which will work for PPC back to 10.2.x, you
must compile ppc and i386 code seperately, and glue the two
executables together with the lipo tool.
Well, you don’t have to use lipo directly. It isn’t difficult to set up
an Xcode project that builds a Universal Binary, compiling the PPC half
with gcc 3 and the intel half with gcc 4. We have such a project for
Aleph One
But missing out on gcc 4 goodness for PowerPC is painful.
Gregory
Hello !
Yeah. otool -L shows the needed version :
Compiling SDL with fatbuild.sh and looking at the PPC Part :--------------------------
libSDL.dylib:
/usr/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current
version 12.1.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
(compatibility version 1.0.0, current version 120.3.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 8.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
(compatibility version 1.0.0, current version 12.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility version 1.0.0, current version 18.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 122.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
63.0.0)
Compiling SDL the standard way :
libSDL.dylib:
/usr/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current
version 12.1.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
(compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 11.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
(compatibility version 1.0.0, current version 6.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility version 1.0.0, current version 22.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
88.1.7)
CU
Heh, tell that to the users. I had a friend who was trying to show
Tux Paint to some kids, and they had an OS X 10.2 system. He had to dig
all over my website to find a link to a 2yo version they could use. 
I’d rather miss out on GCC4 goodness than have 1000s of kids miss out
on Tux Paint 0.9.16 goodness. ;^)On Sat, Dec 02, 2006 at 02:18:48PM -0500, Gregory Smith wrote:
But missing out on gcc 4 goodness for PowerPC is painful.
–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/
Bill Kendrick wrote:
Heh, tell that to the users. I had a friend who was trying to show
Tux Paint to some kids, and they had an OS X 10.2 system. He had to dig
all over my website to find a link to a 2yo version they could use.I’d rather miss out on GCC4 goodness than have 1000s of kids miss out
on Tux Paint 0.9.16 goodness. ;^)
The developer tools come with a 10.2.8 SDK and gcc 3, it’s just an
optional install. Install those, and set up your Xcode project according
to Apple’s guide:
That’s how we build, so 10.2 users are in luck
Gregory
Hello !
Heh, tell that to the users. I had a friend who was trying to show
Tux Paint to some kids, and they had an OS X 10.2 system. He had to dig
all over my website to find a link to a 2yo version they could use.I’d rather miss out on GCC4 goodness than have 1000s of kids miss out
on Tux Paint 0.9.16 goodness. ;^)
When you look at the SDL fatbuild.sh,
it contains SDK settings for 10.3.9.
And the gcc-fat.sh from the other SDL_image, -net
and so on contains settings for 10.2.8
Either this is an error or SDL will not run on 10.2.
CU
Hello !
When you look at the SDL fatbuild.sh,
it contains SDK settings for 10.3.9.And the gcc-fat.sh from the other SDL_image, -net
and so on contains settings for 10.2.8Either this is an error or SDL will not run on 10.2.
My fault: SDL-1.2 will run on 10.2, but SDL-1.3/2.0 not.
CU
Hello Torsten,
Saturday, December 2, 2006, 5:53:03 PM, you wrote:
No, you are wrong. I just tested this with SDL and
used the fatbuild.sh ppc part. I am on a PPC Mac with the latest
XCode Tools and Updates :
OK, my bad 
I did think it was a hunch.
I see no reason why Apple cannot push the new libSystem.dylib out as
an update for 10.2 - it is inexcusable and an obvious attempt at
forcing people to upgrade.
From reading the rest of the thread, it seems that checking
backward compatibility is a huge pain in the ass.–
Best regards,
Peter mailto:@Peter_Mulholland
Hello !
Heh, tell that to the users. I had a friend who was trying to show
Tux Paint to some kids, and they had an OS X 10.2 system. He had to dig
all over my website to find a link to a 2yo version they could use.I’d rather miss out on GCC4 goodness than have 1000s of kids miss out
on Tux Paint 0.9.16 goodness. ;^)
My last question to UBs :
With the help of gcc-fat.sh and more
or less tweaking of the libs, i now have
the wanted UB versions from zlib, libpng,
libjpeg, libfreetype and SDL with fatbuild.sh
was no problem.
When i now try to compile SDL_image for example with
gcc-fat.sh it stops when testing for SDL.
I looked at the config.log and it says it cannot locate
SDLmain.a, but hey it is in /usr/local/lib and i checked
it is also an UB one.
The config.log file is online :
http://www.syntheticsw.com/~wizard/tmp/config_log.txt
The thing is that when i use --disable-sdltest
it the cannot find libpng, libz and libjpeg.
Does gcc-fat.sh somehow turns library using off ?!?
CU