Old macintosh compile discussion

[optic delusion]

EDIT: As far as i know, these instructions still work,but this was from the early days of intel macs. and before BZFlag switched from CVS to SVN. This post is in need of serious updating.
I would do it myself, but I was pretty motivated to have an intel-client at the time, and have done next-to-zero compiles since this time.
If anyone would like to make a new thread, with new instructions,
GO FOR IT!


This assumes you have a spanking-new intel-mac

These compile instructions have only been tested on an Intel macintosh. I have a sneaky suspicion that they will work on a PPC Mac, but I have not seen proof of this, so use extreme care, there are no guarantees. Compiling is not for everyone, and if you get lost in here, you should just forget about the whole thing.

I have included instructions for compiling BZFlag version 2.0.8 from the source tarball located here, http://sourceforge.net/project/showfile ... ge_id=3165 There is no real reason for you to compile 2.0.8 from this source. The pre-built application is available here.
http://sourceforge.net/projects/bzflag/ for PPC
http://eidotter.de/~alexx/bzflag/ for intel mac

Now the real reason to compile BZFlag is to see the latest updates from the devs. For that you need to get version 2.1 from cvs. I have included instructions for this, but I strongly suggest you compile 2.0.8 first, to test that your build environment is set up correctly. At any one moment CVS can be broken, and you will need to know it's not because of something you did. So...
First I'll discuss the build environment, then compiling from the known good 2.0.8 source, then I'll talk about compiling version 2.1 from CVS.


The Build environment is key, without this setup perfectly, you'll go nowhere.
1. Start with a fully updated OSX version 10.4
2. Install Devtools and X-11 from your Apple-supplied disk. Or you can get it from Apple via download. If you can not do this without help, Stop reading, and forget you ever saw these instructions.
3. Run mac software update to get the most current devtools updates. Right now, that's X-Code 2.2.1.
4. Now you need one more thing, Simple DirectMedia Layer, or more specifically, SDL-1.2.10.tar.gz, get it here http://www.libsdl.org/index.php
4a. Double-click on SDL-1.2.10.tar.gz, this will expand the file and produce a folder named SDL-1.2.10
4b. Open your terminal and cd into this folder. If you can't do this, go get yourself a copy of "macintosh for dummies", and spend the next six weeks reading.
4c. Configure SDL with a prefix and to build static libs: (in SDL-dir)
./configure --enable-static --disable-shared --prefix=/Users/your_name/local
4d. Build and install SDL:
make
make install
4e. Now compile the framework-stuff (something OSX-specific, don't really know much about it.., README helps): (in SDL-dir)
tar xzf XCode.tar.gz
cd XCode/SDL
xcodebuild
4f. xcodebuild just magically builds all (or the only one?) XCode-projects in the current directory. So in this case it builds SDL.xcodeproj
After that, there should be a directory build/Default/SDL.framework. This should be moved to /Library/Frameworks, so that it can be found later.
I first tried to copy it, but there must be some strange permissions in this dir which cp ignores without some special parameters. I didn't look them up, because mv just works..
mv build/Default/SDL.framework /Library/Frameworks
4g. SDL is done! on to BZFlag

Compile BZFlag 2.0.8. This should be done before you try CVS to test your build environment.
1. get bzflag-2.0.8.tar.gz from http://sourceforge.net/project/showfile ... ge_id=3165
2. expand it to a folder named BZFlag-2.0.8. then cd into that folder
3. ./autogen.sh
4. Configure BZFlag with the prefix for SDL used above: ./configure --with-sdl-prefix=/Users/your_name/local
4a. If you want BZFS to have plugins use this instead ./configure --with-sdl-prefix=/Users/your_name/local --enable-plugins --enable-shared
5. Now we symlink the SDL-includes into the same directory: This is the step that eluded me for six months.
cd src/platform/MacOSX
ln -s /Users/your-name/local/include/SDL SDL
6. Now cd back to the root of the bzflag-dir and run xcodebuild. This should run without errors.
7. Finally, copy the game-resources into the application-package:
cp -R data/* build/Default/BZFlag.app/Contents/Resources/
8. That's it.. the final application is in build/Default/BZFlag.app You can drag it anywhere you want.

Now before we move on to version 2.1, I'm gonna say a couple things about server plugins. Please refer to step 4 above.
0. If you don't plan on running a server, or if your server won't need plugins, you can skip all of the --enable-stuff.
1. If you have any additional plugins, maybe one you made yourself, add the source for that plugin (including a makefile), to the /bzflag/plugins folder, before running ./configure.
2. for version 2.0.8 use both of these configure options. --enable-plugins --enable-shared
2a. for version 2.1 you only need one option --enable-plugins
3. Most makefiles are designed for Linux. The makefiles provided in the source plugins will build. No guarantee that added plugins will build. I've had mixed results.

Compiling BZFlag 2.1. You don't need the SDL symlink provided above. Use this configure.
1. Get the CVS using instruction posted in another post. Maybe I'll edit this in later.
./autogen.sh
./configure --with-sdl-prefix=...
xcodebuild
cp -R data/* build/Default/BZFlag.app/Contents/Resources/
2. that's it.


P.S.
I hope I don't have egg on my face, and this works for you as well as it did for me. If you try it on a PPC, please let me know what happened, good or bad.
Thanks again for the heads-up Matt?

[optic delusion]

The source tarball is known to be a good source. You should compile that, just to test that your build environment (SDL) is installed correctly. Only after you compile the source tarball, successfully, should you move on to CVS, because if CVS is broken, you'll be sure if it's not your build environment causing the problem.

I hope that is clear now.

[a dead man]

AHHHH at my wits end, no matter what I do in building 2.0.8 (for ppc) I get this error, both on make and xcodebuild:
....
collect2: ld returned 1 exit status
make[2]: *** [bzfs] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
** BUILD FAILED **

little help someone

btw, I'm trying to put teppics autobot patch in, thats why i want to compile. This error comes up both on a standard compile as well as with the patch

OSX 10.4.7

[CannonBallGuy]

This thread is mainly for compiling on an intel mac.

Compiling on PPC should just be:

Code: Select all

cd ~/cvs/bzflag 
./autogen.sh 
./configure; make

[gnu-sense]

I have the SDL.Framework as binary directly from its own download page (version 1.2). Is there any problem with using that?

gnu-sense

[optic delusion]

GNU-Sense... Kinda hard to tell, from here..
I don't think you'll have a problem, as long as bzflag knows where to find SDL. You can symlink to it, but I suggest following the instructions exactly. Many people have done that and reported success.

Also... I should really edit in some instructions for using SVN, as the developers no longer use CVS to store their work.

[macsforme]

I have the SDL.Framework as binary directly from its own download page (version 1.2). Is there any problem with using that?

gnu-sense

I used the precompiled framework when I compiled on my MacBook, and it worked without problems.

[Legolas_]

I have the SDL.Framework as binary directly from its own download page (version 1.2). Is there any problem with using that?

gnu-sense

I used the precompiled framework when I compiled on my MacBook, and it worked without problems.

That sounds like it should work for all, Constitution. I will test it out when I get my new MacBook in a few days. I see no reason why the SDL.Framework would have any problems at all.

[gnu-sense]

I managed to get a compile to work *mostly*; here are some notes about the process. For the record, I am working on a Dual 1.8GHz G5 (PPC), MacOS X 10.4.10, with XCode 2.4.1 installed (an earlier version of XCode was part of my problem before). So far, I am working on the BZFlag 2.0.8 tarball.

(1) Compiling SDL. This worked up to step 4e in Optic's instructions. It turns out that the XCode project is configured to use the MacOS X 10.2.8 SDK for the PPC build. This is for backward compatibility, as explained by notes in the project file, but this SDK is not part of the XCode install, and it seems to be buried on the Apple website. Changing the PPC build to point to the 10.3.9 SDK allows the build to go forward, throwing 45 warnings, six of which are about casting data types, the rest of which flagged deprecated library calls.

Rather than use this library, I proceded with the one I had already installed in /Library/Frameworks (I assume it to be compatible with more OS versions).

(2) Compiling BZFlag 2.0.8. I did this using the XCode GUI. This proceeded fine throwing a bunch of warnings and two errors. The errors were something about not finding the Resources directory. Inspecting the package showed the binaries to be present, so I tried running them. Double-clicking the app simply exits (probably because of the missing data), but running the bzadmin and bzfs binaries appeared to work properly. This is encouraging, as I was anticipating primarily making modifications to the server.

Our tech at work set me up with an account on a linux machine. I'll be trying that too for comparison.

gnu-sense

[macsforme]

(2) Compiling BZFlag 2.0.8. I did this using the XCode GUI. This proceeded fine throwing a bunch of warnings and two errors. The errors were something about not finding the Resources directory. Inspecting the package showed the binaries to be present, so I tried running them. Double-clicking the app simply exits (probably because of the missing data), but running the bzadmin and bzfs binaries appeared to work properly. This is encouraging, as I was anticipating primarily making modifications to the server.

Personally, I build BZFlag on the command line, then run it through the Xcode project (which sometimes does and sometimes does not work). If the app isn't starting, try starting it on the command line once with the -directory option (or put the suitable line in your config file). I'd think that it should be able to find the data directory when you double-click the .app, but this might help in any case.

[Legolas_]

Constitution
I do the same as you. Sometimes I get problems building it with xcode, so I import the files from the regular ppc bzflag file and it loads fine.

[gnu-sense]

I managed to get the 2.0.8 PPC build working by dragging and dropping the contents of the Resources directory of a working package into the Resources of my built package (which only had a BZFlag.icos file). This made the application work normally, XCode does not copy the needed data into the package (but this is in Optic's instructions if I look carefully...).

I've moved on to the svn now, and using the trunk/bzflag directory I have managed to get reasonably far into the compile using the instructions above closely. However, whatever method I used to compile (xcodebuild, XCode GUI, make), compilation exits with the following error:

Code: Select all

g++ -DHAVE_CONFIG_H -I. -I. -I../../include  -I../../include -I../bzflag     -pipe -pedantic -fno-exceptions -W -Wall -Wundef -Wno-import -O3 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -fno-exceptions -g -O2 -c -o SharedObjectLoader.o `test -f 'SharedObjectLoader.cxx' || echo './'`SharedObjectLoader.cxx
SharedObjectLoader.cxx: In member function 'virtual bool SharedObjectLoader::load(std::string)':
SharedObjectLoader.cxx:31: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object
SharedObjectLoader.cxx:32: error: invalid conversion from 'const char*' to 'char*'
SharedObjectLoader.cxx:39: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object
SharedObjectLoader.cxx:40: error: invalid conversion from 'const char*' to 'char*'
make[2]: *** [SharedObjectLoader.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Thinking that I was perhaps having problems with the plugins, I tried configuring it without enabling plugins (./configure --with-sdl-prefix=/Users/gnu-sense/local) and compiling again. Same error. Anyone have any insight into this?

Thanks much,

gnu-sense

[blast]

SVN trunk is the development version of BZFlag. It is currently 2.1, which is not compatible with existing 2.0.x servers. If you want a compatible client/server, see the wiki page for the v2_0branch directions.

In any case, that's just a bug in the code.

[optic delusion]

As far as i know, these instructions still work,bBut this was from the early days of intel macs. and before BZFlag switched from CVS to SVN. This post is in need of serious updating.
I would do it myself, but I was pretty motivated to have an intel-client at the time, but have done next-to-zero compiles since this time.
If anyone would like to make a new thread, with new instructions,
GO FOR IT!

[gnu-sense]

I wonder if some other things should be fixed first. Specifically, there are the following problems:

(a) redundant ./configure is performed by xcodebuild but has to be done first anyway to specify the right options and get the configuration right in the first place.

(b) the xcode project doesn't give edit access to the source code. Yes it compiles it and all, and you can edit the files with xcode and see the pretty syntax coloring, but the IDE doesnt work for the project the way it's supposed to (it doesnt really contain any source code references). Mac development would be much nicer if this were fixed.

(c) there should be separate targets for bzadmin, bzfs and bzflag, and one target that builds the other three plus the app. This would make it easier to compile only, e.g. bzfs, if that is all that is updated, and one wishes to run it as a command-line binary.

(d) copying of the data files to the resouce directory in the app should be done right during the build process, so you can build-and-run (instead of by drag-and-drop, for which you have to launch the app later).

(e) pertinent to the Intel-Mac issue, specifying the build options should be done a little better, so that one can switch between PPC, Intel and Universal binaries more readily.

I was going to attempt the necessary changes to the project file and submit it as a patch, but I'm not an xcode guru (I am learning about these things as time permits), so it's not just a quick thing for me. Please warn me if someone has already done something along these lines. The one potential problem I can see is that references to source files inside the xcode project will need to be kept up-to-date if files are added or deleted from the source tree (i.e. without active mac devs, it will go out of date).

It will also take me some time to get to this, as I have a full stack of other things I really have to do first (school is back in session).

gnu-sense

[CannonBallGuy]

These steps always seem to "work" for me - intel or ppc - but doesn;t always result in a working client, server, etc. This is presumably because code on svn can often be broken....:

1. Get source from SVN like so:

Code: Select all

svn co https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/v2_0branch/bzflag bz2.0-date

or for 2.1:

Code: Select all

svn co https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag bz2.1-date

2. cd into the new bz2.0-date or bz2.1-date fir you just downloaded the source into.

3. Follow the readme and do:

Code: Select all

./autogen.sh
./configure
make

4. Start a client like so:

Code: Select all

./src/bzflag/bzflag -directory ./data

- It's as simple as that.

[Enigma]

This is the first time I have thoroughly read through these instructions, and I have to say, I do not see how these instructions are specific to Intel Macs. What these instructions describe is basically the same for all Macs, except for the steps about SDL, which are not necessary.

4c. Configure SDL with a prefix and to build static libs: (in SDL-dir)
./configure --enable-static --disable-shared --prefix=/Users/your_name/local
4d. Build and install SDL:
make
make install
4e. Now compile the framework-stuff (something OSX-specific, don't really know much about it.., README helps): (in SDL-dir)

Indeed, it seems you are, or were, not familiar with frameworks. This whole step is not necessary, and I really do not know why one would want a static version of SDL instead of a dynamic library, as SDL is likely to be used by more than one application.

To install SDL, all that is required is to place the SDL.framework in a standard search path, either /library/frameworks or ~/library/frameworks. The SDL framework should not be placed in /system/library/frameworks, as that directory is reserved for Apple.

4. Configure BZFlag with the prefix for SDL used above: ./configure --with-sdl-prefix=/Users/your_name/local
4a. If you want BZFS to have plugins use this instead ./configure --with-sdl-prefix=/Users/your_name/local --enable-plugins --enable-shared
5. Now we symlink the SDL-includes into the same directory: This is the step that eluded me for six months.
cd src/platform/MacOSX
ln -s /Users/your-name/local/include/SDL SDL

Parts of these steps are also not necessary, as they are results of how you decided to install SDL. You do not need to use --with-sdl-prefix, as it is not for frameworks. When "-framework SDL" is passed to the compiler, the SDL framework is found if it is in a standard search path, and it is then linked to the application. With frameworks, you do not need to specify where the header files are, as they are in SDL.framework.

cp -R data/* build/Default/BZFlag.app/Contents/Resources/
8. That's it.. the final application is in build/Default/BZFlag.app You can drag it anywhere you want.

I remember doing this a long time ago, and it certainly was slightly annoying. It is not required when creating BZFlag.app with the latest 2.0.9 sources.

(a) redundant ./configure is performed by xcodebuild but has to be done first anyway to specify the right options and get the configuration right in the first place.

I really do not like this either, as it can screw stuff up. It is a run-script build phase that runs autogen.sh, configure, and make. It is probably best to remove ./autogen.sh and ./configure from the script, especially if you want to make plug-ins.


One last thing...

I always strip the bzflag, bzfs, and bzadmin executables after compiling, as it is not automatically done.

Code: Select all

$strip bzflag/src/bzflag/bzflag
$strip bzflag/src/bzfs/bzfs
$strip bzflag/src/bzadmin/bzadmin

Summary


Follow CBG's instructions, and those on the Wiki.

Copy or move SDL.framework into /library/frameworks. (~/library/frameworks is for specific users, I believe)

If you want plug-ins, run configure with "--enable-shared --enable-plugins" for BZFlag2.0.9 and only "--enable-plugins" for BZFlag2.2.

If you are using plugins and are also making the BZFlag app bundle, remove ./configure and ./autogen.sh from the run-script build phase.

Strip the binaries. If they are not stripped, they will be very large.

Please excuse any grammatical errors; it is very late, and I am tired.

[macsforme]

Indeed, it seems you are, or were, not familiar with frameworks. This whole step is not necessary, and I really do not know why one would want a static version of SDL instead of a dynamic library, as SDL is likely to be used by more than one application.

I'm not an expert on this myself, but does statically compiling/linking SDL with BZFlag allow the BZFlag binary to run on machines without the SDL framework installed? If so, then it might be desirable in certain cases.

[Enigma]

Indeed, it seems you are, or were, not familiar with frameworks. This whole step is not necessary, and I really do not know why one would want a static version of SDL instead of a dynamic library, as SDL is likely to be used by more than one application.

I'm not an expert on this myself, but does statically compiling/linking SDL with BZFlag allow the BZFlag binary to run on machines without the SDL framework installed? If so, then it might be desirable in certain cases.

Yes.

If you really want to link to a static library, you should pass "-static" to gcc, as gcc automatically tries to link to dynamic libraries. You would also have to install libsdl as a "normal" library, not a framework, as frameworks are shared libraries. Then pass -L and -I to configure if libsdl is in a nonstandard location.

Now that I think of it, he created a symbolic link to the SDL headers because they were in a nonstandard location. The proper way is to pass "-I/path/to/SDL/headers" to configure.

Here is an example:

Code: Select all

 ./configure LDFLAGS="-L/opt/local/lib" CPPFLAGS="-I/opt/local/include" --enable-shared --enable-plugins

[optic delusion]

I wish enigma (or someone who knows what they are talking about) would make a brand new post to re-explain this... people are still having problems linking their SDL.

Someone got me to modify a local SDL configuration file to permantly link my SDL correctly, but I cant remember where or how.

[Enigma]

It's good enough, and there is some useful information here, I think. We are all learning.

Anyways, I'm not sure if this still happens when compiling 2.0.10, but configure always used to fail with the ld error shown below. You have to look in configure.log to find it. It used to cause a lot of configure's little test programs that test for libraries to fail. The following is from http://www.openscenegraph.org/projects/ ... MacOSX10.5.

Another common problem developers might experience is:

Code: Select all

ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib
collect2: ld returned 1 exit status

Apple has a posted a Technical Q&A (QA1567) on this entitled "Compiling X11 / OpenGL applications on Mac OS X v.10.5 Leopard"

Some people have reported a problem similar to this and/or used the solution posted in this Q&A to resolve a problem building the osgdb_freetype plugin. However, I believe this is the wrong solution to this specific problem. In the osgdb_freetype case, the problem was one of three things: 1) The wrong libfreetype.dylib was being used (wrong SDK) 2) The libfreetype.dylib was not found (wrong path) 3) Extra/unneeded dependencies increasing the chance of triggering the cycle bug

For #1, the Xcode project was linking to /usr/X11R6/lib, but we should have been linking to $(SDKROOT)/usr/X11R6/lib. You would normally experience this problem when compiling against the 10.4u SDK on 10.5.

For #2, the problem was usually experienced by people building against the 10.5 SDK (on 10.5). The problem here is that Leopard has moved from XFree86.org to X.org and the path is now /usr/X11/lib instead of X11R6. Within the SDK, there is no X11R6 path, so the library was not found.
The solution is quite simple. Change the link path line to:

-L$(SDKROOT)/usr/X11/lib -L$(SDKROOT)/usr/X11R6/lib