Gcc-fat v2 v0.0.1

Hello !

Ryan Gordon and maybe others had the idea to create a gcc replacement
to allow on Mac OSX to run gcc one time with the necessary PPC settings
and the second time with the necessary X86 settings and then finally
combine these generated object files or other files with lipo.

http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL_mixer/gcc-fat.sh?revision=2289&view=markup

Yesterday i hacked this gcc-fat version, it does some things different
than gcc-fat.sh, but basically works the same way. gcc-fat.sh created
ppc and x86 directorys for the files, which keeps the build directorys
clean, but needs a lot of hacking when you have something like this :

-o …/bin/test.exe

The two cases then would be

mv …/bin/test.exe …/bin/ppc/test.exe
mv …/bin/test.exe …/bin/x86/test.exe

Now my idea is to simply add _ppc for the ppc version
and _x86 for the x86 version. Also my version supports
more styles for example -c test1.cxx test2.cxx
and also -c test1.cxx test2.cxx -o test.

With my gcc-fat version i was able to compile Universal Binaries
from SDL-1.2 and FLTK-1.1 Other things should work too, but i had not
more time.

So how to use it now :

Download :

http://www.syntheticsw.com/~wizard/tmp/gcc-fat-v0.0.1.tar.gz

Unpack it into for example /tmp

Load main.cxx with an Editor and make changs to the SDK Settings.
( In the next version you will be able to dynamically select which
SDK to use for PPC and which SDK to use for X86 with environment
variables, the same way XCode does )

Then :

c++ GLB_basic.cxx main.cxx -o gcc-fat -DUSE_CC
c++ GLB_basic.cxx main.cxx -o g+±fat -DUSE_CXX

Now we have two replacements, one for gcc and one for g++.

Then type into your commandline :

export CC=/tmp/gcc-fat
export CXX=/tmp/g+±fat

Then you can build SDL and FLTK the normal way.

I know that my usage of String Pointer causes memory leaks.
But every modern OS frees the used memory after the app quits
and it is also no server daemon, so what the heck.

I tested this on a PPC Mac with latest Mac OSX 10.4.x with latest
XCode 2.4.1

Waiting for feedback :slight_smile:

CU

One question, isn’t it possible to simply compile sdl as is decribed
here [1] ?

According to this document if architecture specifics are not decided
at configuration-time but at compile-time (e.g. using endianness
macros) then it is just a matter of passing -arch i386 -arch ppc to
gcc during compilation and linking.

Daniel

[1] <http://developer.apple.com/documentation/Porting/Conceptual/
PortingUnix/compiling/chapter_4_section_3.html>

Hello !

One question, isn’t it possible to simply compile sdl as is decribed
here [1] ?

According to this document if architecture specifics are not decided
at configuration-time but at compile-time (e.g. using endianness macros)
then it is just a matter of passing -arch i386 -arch ppc to gcc during
compilation and linking.

No, just because it is more than only fiddeling with
Little- or BigEndian.

On a PPC Mac for example you need to select on the commandline
/Developers/SDKs/MacOSX10.4u.sdk and -arch ppc and -arch i386
and you get an app that runs on 10.4 at minimum.

Okay for i386 this is no problem, 10.4 was the first with i386
i think, but what about the PPC Users that maybe still use 10.2 or 10.3 ?

On a X86 Mac -arch ppc -arch i386 is enough. As there the standard SDK is
10.4u.sdk, on PPC it is 10.4.0.sdk.

So for example SDL compiles fine down to 10.2, so the best
you can do for your user is to compile a PPC version for 10.2 from SDL
and a X86 version for 10.4 from SDL and combine this to libs with lipo.

When you have done that with SDL, you need to do the same with
your application or game.

As Ryan Gordon had this great idea to let a script do this
for you.

CU