Problems compiling on macintosh.

Questions or HOWTOs about the above? Post 'em here...
Post Reply
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Problems compiling on macintosh.

Post by JeffM » Wed Oct 27, 2004 4:02 pm

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?
Last edited by JeffM on Sat Oct 30, 2004 10:23 pm, edited 2 times in total.
ImageJeffM

User avatar
nurdc0re
Private First Class
Private First Class
Posts: 67
Joined: Sun Mar 21, 2004 2:57 am

Post by nurdc0re » Wed Oct 27, 2004 7:03 pm

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?

User avatar
RPG
Lieutenant, Junior Grade
Lieutenant, Junior Grade
Posts: 2015
Joined: Fri Sep 17, 2004 2:37 am
Location: Chicago, Illinois
Contact:

Post by RPG » Wed Oct 27, 2004 7:47 pm

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.

User avatar
blast
General
General
Posts: 4791
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Post by blast » Wed Oct 27, 2004 9:26 pm

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.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Wed Oct 27, 2004 11:50 pm

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.
ImageJeffM

User avatar
learner
General
General
Posts: 270
Joined: Sun May 11, 2003 2:06 am
Location: Maryland
Contact:

Post by learner » Thu Oct 28, 2004 12:34 am

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!

User avatar
learner
General
General
Posts: 270
Joined: Sun May 11, 2003 2:06 am
Location: Maryland
Contact:

Post by learner » Thu Oct 28, 2004 12:54 am

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!

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Thu Oct 28, 2004 12:59 am

as allways I'd be glad to post OSX builds if somone would donate a macintosh for me to use to build them.
ImageJeffM

User avatar
Lan
Private First Class
Private First Class
Posts: 296
Joined: Sun Jun 13, 2004 1:21 am
Contact:

Post by Lan » Thu Oct 28, 2004 2:13 am

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.

User avatar
nurdc0re
Private First Class
Private First Class
Posts: 67
Joined: Sun Mar 21, 2004 2:57 am

Post by nurdc0re » Thu Oct 28, 2004 7:06 pm

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?

User avatar
learner
General
General
Posts: 270
Joined: Sun May 11, 2003 2:06 am
Location: Maryland
Contact:

Post by learner » Thu Oct 28, 2004 7:28 pm

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!

User avatar
nurdc0re
Private First Class
Private First Class
Posts: 67
Joined: Sun Mar 21, 2004 2:57 am

Post by nurdc0re » Fri Oct 29, 2004 4:58 am

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!

Post Reply