Page 1 of 1

Problems compiling on macintosh.

Posted: Wed Oct 27, 2004 4:02 pm
by JeffM
NOTE***
this thread my look odd, a monkey provided false age infromation, and legaly we can't store any info from him with out consent, so I have to remove his posts. but there is good info here so this thread will stay.


we don't have anyone who is able to build mac versions.

"unix" compatable is kinda an oxymoron.

if your talking about llinux, the only packages that can be made are RPM and debian packages.

if your talking about something else, then building is the general way to get it done. Building is common in the *nix world.

what OS and compiler are you using? and where does it give the error?

Posted: Wed Oct 27, 2004 7:03 pm
by nurdc0re
I know exactly what you mean! When I try to compile on Mac OS X (10.3.5)

Code: Select all

ranlib libObstacle.a
Making all in zlib
make[2]: Nothing to be done for `all'.
Making all in bzfs
source='AccessControlList.cxx' object='AccessControlList.o' libtool=no \
depfile='.deps/AccessControlList.Po' tmpdepfile='.deps/AccessControlList.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../include  -I../../include -I/usr/include -pipe -ansi -pedantic -fno-exceptions -W -Wall -Wundef -Wstrict-prototypes  -g -O2 -O3 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -fno-exceptions -c -o AccessControlList.o `test -f 'AccessControlList.cxx' || echo './'`AccessControlList.cxx
source='Authentication.cxx' object='Authentication.o' libtool=no \
depfile='.deps/Authentication.Po' tmpdepfile='.deps/Authentication.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../include  -I../../include -I/usr/include -pipe -ansi -pedantic -fno-exceptions -W -Wall -Wundef -Wstrict-prototypes  -g -O2 -O3 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -fno-exceptions -c -o Authentication.o `test -f 'Authentication.cxx' || echo './'`Authentication.cxx
source='BZWError.cxx' object='BZWError.o' libtool=no \
depfile='.deps/BZWError.Po' tmpdepfile='.deps/BZWError.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../include  -I../../include -I/usr/include -pipe -ansi -pedantic -fno-exceptions -W -Wall -Wundef -Wstrict-prototypes  -g -O2 -O3 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -fno-exceptions -c -o BZWError.o `test -f 'BZWError.cxx' || echo './'`BZWError.cxx
source='BZWReader.cxx' object='BZWReader.o' libtool=no \
depfile='.deps/BZWReader.Po' tmpdepfile='.deps/BZWReader.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../include  -I../../include -I/usr/include -pipe -ansi -pedantic -fno-exceptions -W -Wall -Wundef -Wstrict-prototypes  -g -O2 -O3 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -fno-exceptions -c -o BZWReader.o `test -f 'BZWReader.cxx' || echo './'`BZWReader.cxx
source='CmdLineOptions.cxx' object='CmdLineOptions.o' libtool=no \
depfile='.deps/CmdLineOptions.Po' tmpdepfile='.deps/CmdLineOptions.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../include  -I../../include -I/usr/include -pipe -ansi -pedantic -fno-exceptions -W -Wall -Wundef -Wstrict-prototypes  -g -O2 -O3 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -fno-exceptions -c -o CmdLineOptions.o `test -f 'CmdLineOptions.cxx' || echo './'`CmdLineOptions.cxx
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h: In function `void 
   parse(int, char**, CmdLineOptions&, bool)':
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/atomicity.h:65: error: `asm' 
   operand requires impossible reload
make[2]: *** [CmdLineOptions.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I really have no idea what is going on, and I updated through anonymous CVS right before I tried this (yes, even did "sh autogen.sh" and "./configure"). Anything I can do?

Posted: Wed Oct 27, 2004 7:47 pm
by RPG
I'm trying to be patient until they realease 1.11.x because:
1. I'd kill myself trying to compile the thing on windows
2. I don't like ruining suprises

OK, my reasons aren't the best, but #1 discourages me from even visiting CVS.

Posted: Wed Oct 27, 2004 9:26 pm
by blast
It truely isn't that hard to compile the CVS version. The main difficulty is the various problems that are encountered during the compile. The CVS is "development" code, so it won't always work on every system/compiler, or even at all. The only real thing you can do is fix the problems that are keeping you from compiling, or wait until someone else does.

Note: For Windows I think you can compile with Dev-C++, but I'm not sure if those project files have been updated yet. Your best bet is probably Visual C++ 7.1 (the .NET version), which is what most of the Windows dev's use.

Posted: Wed Oct 27, 2004 11:50 pm
by JeffM
moving to build help...

So you don't know what version of gcc your using? your "the terminal" can run any number of compilers. try a gcc --help and see what it gives you.

The error looks like a problem in the apple system headers, probably due to the order of inclusion.

Posted: Thu Oct 28, 2004 12:34 am
by learner
That atomacity.h error is a ppc gcc compiler bug. Until I get access to a box that exhibits that same problem, I can't really make a work-around for the compiler bug. It works for myself and other folks compiling on Mac OS X, so builds will still be made. And if one of us gets enough energy to put together a preview build of 1.12, it'll be posted up.

For now, a quick fix is to change the build flags:
./configure --enable-debug
or
./configure CFLAGS="-O2" --enable-debug

That should avoid the issue. Now run off, compile, and be merry .. just don't make annoying "brag" (spam) patches or I won't be inclined to help again. :P

Cheers!

Posted: Thu Oct 28, 2004 12:54 am
by learner
The XCode project is only updated prior to a release right now. So, no. If there's someone else who is willing to maintain the XCode project and keep it up to date, I'd be more than happy to get those changes in so that building with the XCode project actually works too. I've been looking for someone to help in that area for some time, but nobody else has stepped forward.

Cheers!

Posted: Thu Oct 28, 2004 12:59 am
by JeffM
as allways I'd be glad to post OSX builds if somone would donate a macintosh for me to use to build them.

Posted: Thu Oct 28, 2004 2:13 am
by Lan
Blast,
YES! the dev-c++ projects have been updated, they are updated on a regular basis every time files are added, and I have fixed the errors in Sello's post thanks to his help catching them and reporting them, and a human (me) maintains them, so I also fix any other troubles in compilation.

I sure hope this idea that they are not updated doesn't spread, so keep this in mind everyone.

The dev-c++ files are updated and maintained like a charm, so yes use them if you want to.

Posted: Thu Oct 28, 2004 7:06 pm
by nurdc0re
Okay, I have built it (did "make", "make install", etc) and there were no errors.... so now what? I do not have any .app file anywhere to run, so I am not sure what to use?

Posted: Thu Oct 28, 2004 7:28 pm
by learner
After make, the bzflag binary sits in src/bzflag/bzflag. You can run that directly from there on the command line. After make install, the bzflag binary is (by default) installed as /usr/local/bin/bzflag. You can likewise run that on the command line.

Converting the build from a unix tool to a double-clickable .app is not an automatic process (yet). If you really want the shiny-double-clickable-icon, you can make a copy of your existing 1.10.8 .app, and copy the src/bzflag/bzflag into the .app's Contents/MacOS directory. You'll also need to copy all of the contents of the data directory into the .app's Resources directory. If that sounds like gibbrish to you, then stick to running it as a unix command (type "/usr/local/bin/bzflag" on the command line after make install) until the official release is made.

Cheers!

Posted: Fri Oct 29, 2004 4:58 am
by nurdc0re
learner wrote:After make, the bzflag binary sits in src/bzflag/bzflag. You can run that directly from there on the command line. After make install, the bzflag binary is (by default) installed as /usr/local/bin/bzflag. You can likewise run that on the command line.

Converting the build from a unix tool to a double-clickable .app is not an automatic process (yet). If you really want the shiny-double-clickable-icon, you can make a copy of your existing 1.10.8 .app, and copy the src/bzflag/bzflag into the .app's Contents/MacOS directory. You'll also need to copy all of the contents of the data directory into the .app's Resources directory. If that sounds like gibbrish to you, then stick to running it as a unix command (type "/usr/local/bin/bzflag" on the command line after make install) until the official release is made.

Cheers!
Actually, it makes perfect sense and everything is working now, thanks everyone!