OS X - Snapshot and static compile discussion

[monotremata]

So I take it we change the SDL-config.h back to its original byte order now??

[Dominus]

Yes definitely
I'll test it all out tomorrow and will upload a new snapshot when it works...

[monotremata]

Works great so far. Just finished a build 4 mins ago and opened it up and made sure no crashes when clicking on the inventory and disk icons and whatnot..

Now back to trying to figure out how to compile an intel binary on my PPC hehe.
I think I may need to either specify -host=i386-apple-darwin when I run ./configure or I have to manually change the makefile's GCC dependency mode..

Im on Leopard now with XCode 3.1.4 so Im using GCC 4 but I noticed when I run configure normally it puts it in GCC 3 dependency mode since Im running a PPC. Intel binaries can only be built with GCC 4+...
Methinks this is my snag somewhere..

[Dominus]

Thanks for the report.

As for compiling in 386, I'll post some stuff that I set before compiling. Mostly stuff like "export gcc=4.0" or so. Maybe that works. I probably don't have time to do that tonight, so tomorrow

[monotremata]

Aaaargh I got all the way to the end of the i386 compile and it died putting together the ogg/vorbis stuff at the very end..

I found out the other day that a standard default SDL install makes universal libs (but not the dynamic ones) so I should be all good there using the static library configuration.. That and the fact that Macports SDL is screwed and doesnt work.

However once I installed it to /usr/local, I couldnt get gcc to find my libvorbis and libogg stuff I installed under Macports so I had to manually install those.
Guess because those are the two libs Im using that arent Universal Ive gotta recompile those..

SCUMM VM and Firefox dev gave me most of the info so far I needed to pass to CFLAGS, LDFLAGS, CPP, etc, etc... I just went and manually changed the Makefile this time around to test and so far so good..

I gotta start taking notes so I dont forget what Im doing haha!

[Dominus]

Ok, here is what I'm doing these days when I'm compiling the snapshot in the VM running Leopard:
- I got semi-rid of MacPorts, I haven't deleted it since it gives insight in some patches and configure options
- created two seperate prefixes for both ppc and intel by making the directories /opt/exult.ppc and /opt/exult.i386
- get rid of the macports paths in ~/.profile
- compile all the needed stuff manually for each prefix and looking at the macports port files of each to make sure you do the right stuff and maybe add patches. For most when you download the release it is enough to just run

Code: Select all

export PATH=/opt/exult.ppc/bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
(or for the intel prefix
export PATH=/opt/exult.i386/bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin)
./configure --prefix=/opt/exult.ppc (or i386)
make clean
make
make install

running ./autogen.sh is mostly not needed.
I may have used some of the environment settings I'm using in my built script for Exult, they could be usefull so maybe include them, too).
I'm running make clean to get rid of the other arch stuff so I'm not accidently polluting one arch with stuff from the other.

- autoconf (2.67 doesn't need patches but /opt/exult.xxx/bin/autoreconf might need to have libtoolize changed to glibtoolize when we do libtool later on)
- automake
- libtool (configure could need --program-prefix=g to make it stand out against the libtool that comes with xcode and that's why autoreconf needs to be changed accordingly)
- pkg-config (it's needed at least for libvorbis, for configure macport uses: --enable-indirect-deps --with-pc-path=${prefix}/lib/pkgconfig:${prefix}/share/pkgconfig )
- zlib (macports applies a patch to makefile.in to line 136 and adds libz.a to
$(SHAREDLIBV): $(PIC_OBJS)
so that it looks like
$(SHAREDLIBV): $(PIC_OBJS) libz.a
- SDL (download or checkout the latest snapshot of the 1.2x branch, if you download the package from http://www.libsdl.org/hg.php you just need to run configure with the prefix, if you don't care about compiling Exult Studio you cann also configure it with --without-x.
Macports aplies a patch to src/video/x11/SDL_x11gl_c.h to add
#include
beneath
#if SDL_VIDEO_OPENGL_GLX
#include )
- libogg
- libvorbis

So after you have done that for both prefixes you have your environment set up. To finally compile an universal Exult I use this script (with the trunk of Exult placed in ~/code/svn/exult/trunk):

Code: Select all

#!/usr/bin/env bash
cd ~/code/svn/exult/trunk
#i386
OPT=' -arch i386 -m32 -O2 -msse -msse2 -force_cpusubtype_ALL '
SDK=' -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -I/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/ '
export MACOSX_DEPLOYMENT_TARGET=10.4
export PATH=/opt/exult.i386/bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
export CC="/usr/bin/gcc-4.0 -arch i386"
export CXX="/usr/bin/g++-4.0 -arch i386"
export GCOV="/usr/bin/gcov-4.0 -arch i386"
export CPPFLAGS='-I/opt/exult.i386/include '$SDK
export CFLAGS='-I/opt/exult.i386/include '$SDK' '$OPT
export CXXFLAGS='-I/opt/exult.i386/include '$SDK' '$OPT
export LDFLAGS='-L/opt/exult.i386/lib '$SDK' '$OPT
./autogen.sh
./configure --disable-sdltest --disable-oggtest --disable-vorbistest --disable-alsa --disable-fluidsynth --enable-mt32emu --enable-static-libraries --with-macosx-static-lib-path=/opt/exult.i386/lib --prefix=/opt/exult.i386 --disable-tools
make clean
make
strip exult
cp -p exult exult-intel
make distclean
#ppc
OPT=' -arch ppc -m32 -O2 ' 
SDK=' -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -I/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/ '
export MACOSX_DEPLOYMENT_TARGET=10.4
export PATH=/opt/exult.ppc/bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
export CC="/usr/bin/gcc-4.0 -arch ppc"
export CXX="/usr/bin/g++-4.0 -arch ppc"
export GCOV="/usr/bin/gcov-4.0 -arch ppc"
export CPPFLAGS='-I/opt/exult.ppc/include '$SDK
export CFLAGS='-I/opt/exult.ppc/include '$SDK' '$OPT
export CXXFLAGS='-I/opt/exult.ppc/include '$SDK' '$OPT
export LDFLAGS='-L/opt/exult.ppc/lib '$SDK' '$OPT
./autogen.sh
./configure --disable-sdltest --disable-oggtest --disable-vorbistest --disable-alsa --disable-fluidsynth --enable-mt32emu --enable-static-libraries --with-macosx-static-lib-path=/opt/exult.ppc/lib --prefix=/opt/exult.ppc --disable-tools
make clean
make
strip exult
cp -p exult exult-ppc
lipo -create -arch i386 exult-intel -arch ppc exult-ppc -output exult
make bundle
make osxdmg

I hope this very lengthy post helps you
Now I need to test my fresh snapshot on the ppc machine before uploading...

[Dominus]

Ok, tested the fix and it seems to work without crashes and with correct sfx now. Thanks colourless. The new snapshot has been uploaded.

[monotremata]

Ok just two questions before I get started hehe..

1. When you said you compile all the needed stuff manually for each prefix, does this means all the tools and libs like autoconf, automake, libtool, zlib, vorbis, sdl, etc?? Im assuming I cant simply build an i386 binary with just ppc libs.. Do you put make em all in the respective /opt/exult.cpu folders to keep em seperate from the normal system??

2. where the heck are the portfiles located? Id like to take a look at how they pull off the universal builds for sure.. SDL was a pain although your export variables I think will do the trick for me in the meantime!

[Dominus]

1. Yes all the stuff I wrote in the lengthy post each need to be installed in either cpu folders. When you add the --prefix=/opt/exult.cpu to each configure options, "make install" will put the compiled stuff automatically in the correct location. So except for adding the prefix option no manual work required. And yes it's meant to be seperate from the system, so you don't mess up your system.

2. The port files are located in /opt/local/var/macports/sources... But it won't help you much since the port files are just telling macports to build the files universally
But you can run port -v install blabla to get a verbose output.

[monotremata]

Almost there.. I keep running into the same error everytime I try and build anything i386 based.. Ive got all the CC/CXX/CFLAGS/CXXFLAGS/etc all exported properly.. I can see gcc-4.0 using the switch -arch i386 but every damn time during configure I run into this:

checking whether we are cross compiling... configure: error: in `/Users/mothra/dev/exult':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

This is actually building Exult itself..

When I started last night, I basically took the i386 half of your script and adapted it so I could use it as a buildscript for manually compiling my libraries and tools into /opt/exult.i386 (obviously removing anything specific to configuring and making Exult).. I kept getting this error just about every package I tried so I was using ./configure --host=powerpc-apple-darwin --build=powerpc-apple-darwin --target=i386-apple-darwin.. And most of them seemed to go just fine.. This morning while finishing up, libvorbis is still the one that wont build right this way.. Looking at my other libs, I have no clue if theyre actually i386 or not, because info from the finder just says theyre all Mach-O Dynamic Libraries.

Frustrated I went back and reinserted the Macports paths into my .profile and re-built everything universally there.. THEN I decided to try your script and build Exult but failed..

Im running the ppc half of your script (basically a cut and paste of everything from the line #ppc to the renaming of Exult to Exult-ppc) and it seems to be running fine, of course until it begins the SDL part and craps out on Macports borked SDL install..
Its only when I tell gcc -arch i386 that it always gives me that cross-compiling error.. Which as it is makes no sense..
If I cant tell it 'Hey make me an i386 build' then how the hell is it supposed to know to automatically cross-compile like it says???

As far as using your script for building Exult... Since Im currently not using the exult.cpu directories, I changed those paths back to /opt/local. I also removed the exported Path lines since all of these locations are already in my path. Then I took the i386 half (from the top all the way to 'make distclean') and saved it as i386.sh.. Did the same thing to the PPC half and made a ppc.sh script..

Im building both targets in the /dev/exult directory so Ill just run the lipo section manually when/if it gets done..

Whats odd is, I ran Macports with the -v option everytime to watch what it did.. I swear from what I could tell, all it did to build those universally was enter in the same damn compiler options using -arch i386 and -arch ppc, same as we did but not once did I ever see an error about not being able to cross compile and the warning to not use --host..

Ive done port -v build whatever +universal so I could check out the Makefiles and whatnot but it doesnt look like theyre really doing much different then I am with the CFLAGS and whatnot..

[Dominus]

you can get info on the archtitecture of files by "lipo -info pathtofile"

In other news, I'm now testing to build the Exult snapshot on my 10.6 machine instead of a 10.5 VM. My tests showed it is working fine and I am now providing a threeway universal build including intel 32bit, intel 64bit and PPC.
Since intel OS X 10.5 will choke on 64bit built on OS X 10.6 I have included a some lines in the plist of the bundle that prevents OS X 10.5 from running the 64bit part of the binary (see http://www.cimgf.com/2009/10/31/limitin ... t-to-10-6/).
I was not able to build 64bit in my leopard VM and honestly I'm much happier this way, not needing to run the VM (each arch building in about 4 minutes instead of 8 or ten). The snapshot image grows about 1.2 MB.

Again I would need some confirmation that it runs on as usual on your PPC leopard

[monotremata]

So far so good here!

Funny thing, since upgrading to Leopard, everything has taken a serious performance hit but Exult still runs as smooth as ever hehe..

Thanks for that info on lipo.. I had seen someone mention a command they were using in terminal to tell them that info but I couldnt for the life of me find it again! Ran across that during my mad google 'build universal sdl' searches a couple weeks ago hehe..