Jump to content
XCOMUFO & Xenocide

Compiling For Os X


smullie

Recommended Posts

Hi everyone,

I've read on these threads that people have gotten UFO2000 running on OS X, so I decided to give it a try, but I'm running in some problems installing the latest version (0.7.946).

 

First I installed subversion and got the latest version of UFO2000. I then installed all the prerequisite libraries, using Fink for Expat and libpng, a pre-compiled binary for Lua (as a framework), and manually compiled HawkNL and Allegro. I modified the makefile so it would find the Fink installs by adding "-I/sw/include" at line 49.

After a lot of twiddling I finally got to the point where I can no longer make sense of the error I get. Running make with -d, I get the following output:

g++: unrecognized option `-pthread'

ld: can't locate file for: -lpng

 

after which it terminates with

 

make: *** [ufo2000] Error 1

 

I would assume that this means there is something wrong with libpng, but I do have libpng installed however, and it does seem to find it as well (before I modified the makefile, it would complain it could not find png.h, I did not get that error message any more after the modification and make got beyond that point without any problems afterwards).

 

Can anyone give me any pointers? Could someone who has succesfully built UFO2000 for OS X perhaps start a thread how he/she managed it?

 

Thanks very much, Jonck

Link to comment
Share on other sites

I have never seen OS X myself, but will try to give some hints anyway. Installing lua is not necessery as lua is included into ufo2000 source tree. Most likely you can just remove that '-pthread' option safely (but I wonder if it is just a warning or a serious error, if it is a warning we can keep it in the makefile as it is important for linux). About '-lpng', the linker can't find a libpng library. In order to successfully use a library, both header files (*.h) and the library itself (*.a or *.so) should be available. You have pointed the compiler to the place where you have the headers using -I switch, a similar switch -L is used to specify the library files location. Look for libpng.a and add '-L directory_with_libpng_a' to CFLAGS in the makefile.

 

Good luck and feel free to ask if you still have any troubles :)

Link to comment
Share on other sites

Thank you for your reply. I tried your suggestion of the -L switch (had actually tried this before, but the Fink FAQ had told me that I should set the -L switch for the LDFLAGS variable, which I could not find in the makefile), it still doesn't work, but at least it's giving a different error now :)

 

After reaching the point where it formerly gave the libpng error, it now gives the following output (have not yet removed the -pthread option, since it seems to progress past it without much of a hickup):

 

g++: unrecognized option `-pthread'

ld: multiple definitions of symbol _NXArgc

/usr/lib/crt1.o definition of _NXArgc in section (__DATA,__data)

/usr/lib/libNL.dylib definition of _NXArgc in section (__DATA,__data)

ld: multiple definitions of symbol _NXArgv

/usr/lib/crt1.o definition of _NXArgv in section (__DATA,__data)

/usr/lib/libNL.dylib definition of _NXArgv in section (__DATA,__data)

ld: multiple definitions of symbol ___darwin_gcc3_preregister_frame_info

/usr/lib/gcc/darwin/3.3/crt2.o definition of ___darwin_gcc3_preregister_frame_info in section (__TEXT,__text)

/usr/lib/libNL.dylib definition of ___darwin_gcc3_preregister_frame_info in section (__TEXT,__text)

ld: multiple definitions of symbol ___progname

/usr/lib/crt1.o definition of ___progname in section (__DATA,__data)

/usr/lib/libNL.dylib definition of ___progname in section (__DATA,__data)

ld: multiple definitions of symbol _environ

/usr/lib/crt1.o definition of _environ in section (__DATA,__data)

/usr/lib/libNL.dylib definition of _environ in section (__DATA,__data)

ld: multiple definitions of symbol start

/usr/lib/crt1.o definition of start in section (__TEXT,__text)

/usr/lib/libNL.dylib definition of start in section (__TEXT,__text)

make: *** [ufo2000] Error 1

 

This, I must admit, no longer means anything to me. Does this ring any bells for you?

 

Thanks so much, Jonck

Link to comment
Share on other sites

The last error messages probably indicate that hawknl library is built incorrectly. Try to compile some of the hawknl examples to check if you get the same error. Unfortunately hawknl does not support a normal './configure -> make -> make install' installation sequence and needs some makefiles hacking. Maybe there is something written about installing for OS X in their readme files?

 

PS. That hawknl library causes the most problems for us, that's another reason to get rid of it some time in the future.

 

edit: Just checked hawknl message board and found this link: http://www.hawksoft.com/boards/opennl/messages/1423.html

There is no answer or any other hint or advice for a long time. HawkNL definitely wins 'the worst support ever' title :(

Edited by Serge
Link to comment
Share on other sites

The last error messages probably indicate that hawknl library is built incorrectly. Try to compile some of the hawknl examples to check if you get the same error. Unfortunately hawknl does not support a normal './configure -> make -> make install' installation sequence and needs some makefiles hacking. Maybe there is something written about installing for OS X in their readme files?

 

PS. That hawknl library causes the most problems for us, that's another reason to get rid of it some time in the future.

 

edit: Just checked hawknl message board and found this link: http://www.hawksoft.com/boards/opennl/messages/1423.html

There is no answer or any other hint or advice for a long time. HawkNL definitely wins 'the worst support ever' title :(

 

Thanks for the tips! At least now I know where to look :)

 

The compilation of HawkNL looks straighforward enough, it would seem that

make --makefile=makefile.osx

sudo make --makefile=makefile.osx install

 

should work, but I guess that's not it, since I did that the first time. Hmmm.... time for some more Googling :)

 

Thanks again for your help!

Link to comment
Share on other sites

The compilation of HawkNL looks straighforward enough, it would seem that

make --makefile=makefile.osx

sudo make --makefile=makefile.osx install

 

should work, but I guess that's not it, since I did that the first time. Hmmm....  time for some more Googling  :)

 

 

Did you get any compilation errors or warnings?

 

I have not had a MacOS programmer giving me feedback on HawkNL for a couple of years, so I REALLY need someone to help me fix this build problem.

 

Phil Frisbie, Jr.

Hawk Software

Link to comment
Share on other sites

Did you get any compilation errors or warnings?

 

I have not had a MacOS programmer giving me feedback on HawkNL for a couple of years, so I REALLY need someone to help me fix this build problem.

 

Phil Frisbie, Jr.

Hawk Software

 

No, no warnings, here is my console output of everything I did:

 

BertPowerbook:~/Desktop/HawkNL1.68/src jonck$ make --makefile=makefile.osx

c++ -o libNL.1.6.8.dylib crc.o errorstr.o nl.o sock.o group.o loopback.o err.o thread.o mutex.o condition.o nltime.o -dylib -r -lpthread -Wl,-x -Wall -fPIC -I../include -funroll-all-loops -ffast-math -fomit-frame-pointer -O2 -D_REENTRANT -DMACOSX

ar cru libNL.a crc.o errorstr.o nl.o sock.o group.o loopback.o err.o thread.o mutex.o condition.o nltime.o

ranlib libNL.a

BertPowerbook:~/Desktop/HawkNL1.68/src jonck$ sudo make install --makefile=makefile.osx

 

*************************************************

* If you forgot to su to root, this probably *

* wont work *

*************************************************

cp libNL.1.6.8.dylib /usr/lib

cp libNL.a /usr/lib

chmod 755 /usr/lib/libNL.1.6.8.dylib

ln -s /usr/lib/libNL.1.6.8.dylib /usr/lib/libNL.1.6.dylib

ln -s /usr/lib/libNL.1.6.8.dylib /usr/lib/libNL.1.dylib

ln -s /usr/lib/libNL.1.6.8.dylib /usr/lib/libNL.dylib

cp ../include/nl.h /usr/include/nl.h

chmod 644 /usr/include/nl.h

 

*************************************************

* Installed HawkNL. *

* Remember to run /sbin/ldconfig before using *

* the library, you may also want to check that *

* /usr/lib is included in /etc/ld.so.conf *

* You must be root to run ldconfig. *

*************************************************

 

 

I searched for ldconfig, but it was not located anywhere on my machine. I Googled it and was led to the idea that ldconfig was a Linux tool and was not necessary on OS X (is this correct?).

 

When I go HawkNL1.68/samples/mac and run

 

gcc test.c

 

I get the following output:

ld: Undefined symbols:

_nlAcceptConnection

_nlAddrToString

_nlClose

_nlConnect

_nlGetError

_nlGetErrorStr

_nlGetLocalAddr

_nlGetRemoteAddr

_nlGetString

_nlGetSystemError

_nlGetSystemErrorStr

_nlInit

_nlListen

_nlOpen

_nlRead

_nlSelectNetwork

_nlShutdown

_nlStringToAddr

_nlWrite

 

Does this give you any clues as to what could be wrong?

 

Kind regards, Jonck

Link to comment
Share on other sites

From http://fink.sourceforge.net/doc/porting/porting.en.html (section 2.2):

 

When creating a shared library, you can specify a name to be used when searching for the library at run time. This is usual practice and allows several major versions of a library to be installed at the same time. On ELF systems this is called the soname. What's different on Darwin is that you can (and should) specify a full path along with the file name. This eliminates the need for "rpath" options and the ldconfig/ld.so.cache system. To use a library that is not yet installed, you can set the DYLD_LIBRARY_PATH environment variable; see the dyld man page for details.

 

So this could explain something of the "multiple definitions" errors perhaps? Does anyone have any idea how to use dyld? I read the man pages, but am not much wiser from them.

 

Kind regards, Jonck

Link to comment
Share on other sites

gcc test.c

You forgot '-lNL' here, so no surprise that functions from hawknl can't be found. Try 'gcc text.c -lNL' and check if it links properly or issues the same double symbols definitions error. In the case if it builds properly using a standard example, that would mean that we have some wrong options in our makefile that are not working in MacOS which need to be fixed and that's definitely just our problem.

Link to comment
Share on other sites

You forgot '-lNL' here, so no surprise that functions from hawknl can't be found. Try 'gcc text.c -lNL' and check if it links properly or issues the same double symbols definitions error. In the case if it builds properly using a standard example, that would mean that we have some wrong options in our makefile that are not working in MacOS which need to be fixed and that's definitely just our problem.

 

Ah ok, thanks. As you will probably have noticed I'm somewhat of a novice when it comes to compiling C stuff, my programming experience is mainly Java and PHP.

 

Running it as you said, produces the same output however:

 

BertPowerbook:~/Desktop/HawkNL1.68/samples/mac jonck$ gcc test.c -INL

ld: Undefined symbols:

_nlAcceptConnection

_nlAddrToString

_nlClose

_nlConnect

_nlGetError

_nlGetErrorStr

_nlGetLocalAddr

_nlGetRemoteAddr

_nlGetString

_nlGetSystemError

_nlGetSystemErrorStr

_nlInit

_nlListen

_nlOpen

_nlRead

_nlSelectNetwork

_nlShutdown

_nlStringToAddr

_nlWrite

 

 

Could it be that I don't have my PATH variable set up correctly? I do have it pointing at everything HawkNL produced as far as I can tell (the output of compiling HawkNL shows that everything goes in either /usr/lib or /usr/include), here is my PATH variable:

 

BertPowerbook:~ jonck$ echo $PATH

/usr/local/mysql/bin:/sw/bin/init.sh:/sw/bin:/sw/sbin:/usr/local/bin:/usr/local/include:/usr/bin:/usr/sbin:/usr/include:/usr/lib:/bin:/sbinsb:/usr/local/apache-ant-1.6.1/bin:/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin

 

I know that in Java a lot of mistakes are due to wrong CLASS_PATH settings, so perhaps this is the case here as well?

 

Thanks, Jonck

Link to comment
Share on other sites

Just read through some man pages of gcc, and tried the following:

 

BertPowerbook:~/Desktop/HawkNL1.68/samples/mac jonck$ gcc -print-search-dirs

install: /usr/libexec/gcc/darwin/ppc/3.3/

programs: =/usr/libexec/gcc/darwin/ppc/3.3/

/usr/libexec/gcc/darwin/ppc/3.3/

/usr/libexec/gcc/darwin/ppc/

/usr/local/libexec/gcc/darwin/ppc/3.3/

/usr/local/libexec/gcc/darwin/ppc/

/usr/libexec/gcc/darwin/../../ppc-darwin/bin/ppc/3.3/

/usr/libexec/gcc/darwin/../../ppc-darwin/bin/

libraries: =/usr/libexec/gcc/darwin/ppc/3.3/

/usr/local/libexec/gcc/darwin/ppc/3.3/

/usr/libexec/gcc/darwin/../../ppc-darwin/lib/ppc/3.3/

/usr/libexec/gcc/darwin/../../ppc-darwin/lib/

/usr/lib/gcc/darwin/ppc/3.3/

/usr/lib/gcc/darwin/

/usr/libexec/gcc/darwin/ppc/3.3/../../../ppc/3.3/

/usr/libexec/gcc/darwin/ppc/3.3/../../../

/lib/ppc/3.3/

/lib/

/usr/lib/ppc/3.3/

/usr/lib/

 

So /usr/include is not on the list of search directories.... that seems like it could be causing these problems, no? I guess the PATH variable is used by the UNIX console only and that gcc needs other settings. Time for some more Googling :)

Link to comment
Share on other sites

Ah ok, thanks. As you will probably have noticed I'm somewhat of a novice when it comes to compiling C stuff, my programming experience is mainly Java and PHP.

That's not a problem :)

 

Running it as you said, produces the same output however:

 

BertPowerbook:~/Desktop/HawkNL1.68/samples/mac jonck$ gcc test.c -INL

Actually that's not quite as I said, '-lNL' and '-INL' are different though they look similar when read from screen (lowercase L and capital I) :) Try to copy the compilation command exactly using the clipboard and report the results.

 

Could it be that I don't have my PATH variable set up correctly? I do have it pointing at everything HawkNL produced as far as I can tell (the output of compiling HawkNL shows that everything goes in either /usr/lib or /usr/include), here is my PATH variable:

 

The following environment variables control the directories used by gcc for finding include/library directories.

export C_INCLUDE_PATH=/usr/local/include:/usr/include:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=/usr/local/include:/usr/include:$CPLUS_INCLUDE_PATH
export LIBRARY_PATH=/usr/local/lib:/usr/lib:$LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/lib:/usr/lib:$LD_LIBRARY_PATH

You might want to add these lines to your '.bash_profile' (if MacOS is similar to Linux in this respect).

Link to comment
Share on other sites

Actually that's not quite as I said, '-lNL' and '-INL' are different though they look similar when read from screen (lowercase L and capital I) :) Try to copy the compilation command exactly using the clipboard and report the results.

 

Ok! After putting the export commands in my .bash_profile as you said (indeed OS X also uses the bash like Linux) and running the gcc command (this time after copy-pasting it :) ) I get the following output:

 

BertPowerbook:~/Desktop/HawkNL1.68/samples/mac jonck$ gcc test.c -lNL

ld: multiple definitions of symbol _NXArgc

/usr/lib/crt1.o definition of _NXArgc in section (__DATA,__data)

/usr/lib/libNL.dylib definition of _NXArgc in section (__DATA,__data)

ld: multiple definitions of symbol _NXArgv

/usr/lib/crt1.o definition of _NXArgv in section (__DATA,__data)

/usr/lib/libNL.dylib definition of _NXArgv in section (__DATA,__data)

ld: multiple definitions of symbol ___darwin_gcc3_preregister_frame_info

/usr/lib/gcc/darwin/3.3/crt2.o definition of ___darwin_gcc3_preregister_frame_info in section (__TEXT,__text)

/usr/lib/libNL.dylib definition of ___darwin_gcc3_preregister_frame_info in section (__TEXT,__text)

ld: multiple definitions of symbol ___progname

/usr/lib/crt1.o definition of ___progname in section (__DATA,__data)

/usr/lib/libNL.dylib definition of ___progname in section (__DATA,__data)

ld: multiple definitions of symbol _environ

/usr/lib/crt1.o definition of _environ in section (__DATA,__data)

/usr/lib/libNL.dylib definition of _environ in section (__DATA,__data)

ld: multiple definitions of symbol start

/usr/lib/crt1.o definition of start in section (__TEXT,__text)

/usr/lib/libNL.dylib definition of start in section (__TEXT,__text)

 

So this is quite an improvement, since now we now know that it's definitely HawkNL that's causing the problems here. Phil, I hope you're still following this thread, do you have any suggestions as to compiling HawkNL?

 

Thanks, Jonck

P.S. it looks like crt1.o is colliding with libNL.dylib, do you have any idea what this crt1.o library is?

Edited by smullie
Link to comment
Share on other sites

Another question just to be sure :) Did you remove all the traces of HawkNL 1.68 before trying 1.66? I definitely had a report about successful build of ufo2000 for MacOS, though this message is now lost and I don't remember what version of HawkNL was used that time.
Link to comment
Share on other sites

Another question just to be sure :) Did you remove all the traces of HawkNL 1.68 before trying 1.66? I definitely had a report about successful build of ufo2000 for MacOS, though this message is now lost and I don't remember what version of HawkNL was used that time.

 

Yes, I removed every file that was created by HawkNL each time before I re-compiled.

 

It's too bad that the person who did succeed in building ufo2000 for OS X is not following this thread, I'm sure he/she would have some useful pointers.

 

Oh well, we'll figure it out someday :)

Edited by smullie
Link to comment
Share on other sites

just only install the static nl lib - the dylib causes the proble.

ufo2000 compiles and runs on OSX 10.3 - NOT on 10.4 though

 

Once in the game, there's a different bug - the mouse cursor's off...

(check the ufo2000 development mailing list archives - if there is a thing like that - there are more detailed instructions of how I got it to start (even made code for a bundle and a working xcode project but it was kindly rejected)

Link to comment
Share on other sites

just only install the static nl lib - the dylib causes the proble.

ufo2000 compiles and runs on OSX 10.3 - NOT on 10.4 though

 

Once in the game, there's a different bug - the mouse cursor's off...

(check the ufo2000 development mailing list archives - if there is a thing like that - there are more detailed instructions of how I got it to start (even made code for a bundle and a working xcode project but it was kindly rejected)

 

Hi,

Thanks for your reply first of all! Good to hear from someone who's managed it. I tried doing what you suggested (Googled the mail archives and did find a mail with some instructions), but I think I did something wrong, since the errors were the same.

 

The message in the mail archives state to remove all the libNL.dylib files without the complete version number, then take libNL.1.6.8.dylib and rename that to libNL.dylib. This however, does not work for me.

 

When installing HawkNL it installs the following files:

/usr/lib/libNL.1.6.8.dylib

/usr/lib/libNL.a

/usr/include/nl.h

and it creates the following symlinks:

/usr/lib/libNL.1.6.dylib

/usr/lib/libNL.1.dylib

/usr/lib/libNL.dylib

 

Could you tell me what you mean by only installing the static nl lib? Which files should I ditch and wich ones should I keep?

 

Thanks, Jonck

Link to comment
Share on other sites

Hi All,

 

I had a very similar problem compiling my own software on MacOSX and this appeared to fix it. The problem that you are probably running into is that HawkNL is not compiled properly. The Makefile has a -dylib flag on line 16 (HawkNL 1.68) this flag should actually be -dynamiclib. Without this crt1.o gets linked into the library (this is an executable stub, and it defines the entry point).

 

HawkNL is a phenomenal crossplatform library that is produced by one guy in his spare time. I wouldn't say that there is horrible support. Its free software and if there is a problem with it, then one should consider finding the issue and fixing it. (Thats just my 2 cents worth)

 

Regards,

Chris

Link to comment
Share on other sites

Hi All,

 

I had a very similar problem compiling my own software on MacOSX and this appeared to fix it.  The problem that you are probably running into is that HawkNL is not compiled properly.  The Makefile has a -dylib flag on line 16 (HawkNL 1.68) this flag should actually be -dynamiclib.  Without this crt1.o gets linked into the library (this is an executable stub, and it defines the entry point).

 

HawkNL is a phenomenal crossplatform library that is produced by one guy in his spare time.  I wouldn't say that there is horrible support.  Its free software and if there is a problem with it, then one should consider finding the issue and fixing it.  (Thats just my 2 cents worth)

 

Regards,

Chris

 

Hi Chris,

Thanks for your reply! I did as you said, the old error has gone, but has sadly been replace by another. When I now try to compile ufo200, I get the following output:

 

ld: Undefined symbols:

_gk_create_allegro_font

_gk_create_keeper

_gk_create_renderer

_gk_done_keeper

_gk_done_renderer

_gk_library_cleanup

_gk_load_face_from_file

_gk_rend_set_size_pixels

_gk_unload_face

make: *** [ufo2000] Error 1

 

Any idea what I should do to fix this?

 

Thanks, Jonck

Link to comment
Share on other sites

Hi All,

 

I had a very similar problem compiling my own software on MacOSX and this appeared to fix it.  The problem that you are probably running into is that HawkNL is not compiled properly.  The Makefile has a -dylib flag on line 16 (HawkNL 1.68) this flag should actually be -dynamiclib.  Without this crt1.o gets linked into the library (this is an executable stub, and it defines the entry point).

 

HawkNL is a phenomenal crossplatform library that is produced by one guy in his spare time.  I wouldn't say that there is horrible support.  Its free software and if there is a problem with it, then one should consider finding the issue and fixing it.  (Thats just my 2 cents worth)

 

Regards,

Chris

 

Hi Chris,

Thanks for your reply! I did as you said, the old error has gone, but has sadly been replace by another. When I now try to compile ufo200, I get the following output:

 

ld: Undefined symbols:

_gk_create_allegro_font

_gk_create_keeper

_gk_create_renderer

_gk_done_keeper

_gk_done_renderer

_gk_library_cleanup

_gk_load_face_from_file

_gk_rend_set_size_pixels

_gk_unload_face

make: *** [ufo2000] Error 1

 

Any idea what I should do to fix this?

 

Thanks, Jonck

 

 

Those errors appear to be allegro/graphics library errors. I actually haven't tried compiling UFO2000 (Just heard about it today) but it sounds like you don't have the library included in your link line? can you paste the line that UFO2000 uses for linking? it should be something like:

 

g++ -o binaryname file1.o file2.o file3.o -L/usr/lib -L/usr/local/lib -lallegro -lNL -framework OpenGL

 

 

Actually... I just did a little more looking into it... and it appears to be a library called GlyphKeeper (basically a fontmanager for allegro) So you might need to link against that library.

Edited by Slice
Link to comment
Share on other sites

Those errors appear to be allegro/graphics library errors.  I actually haven't tried compiling UFO2000 (Just heard about it today) but it sounds like you don't have the library included in your link line?  can you paste the line that UFO2000 uses for linking?  it should be something like:

 

g++ -o binaryname file1.o file2.o file3.o -L/usr/lib -L/usr/local/lib -lallegro -lNL -framework OpenGL

 

 

Actually... I just did a little more looking into it... and it appears to be a library called GlyphKeeper (basically a fontmanager for allegro)  So you might need to link against that library.

 

I'm afraid I'm pretty new to make files. I've learned a lot these days, but I don't quite know what to do when you say that I should link against the GlyphKeeper library. I found a directory called "glyphkeeper" in the src directory of ufo200, so I tried adding

-I src/glyphkeeper

to line 49 of the ufo2000 makefile, but this appeared to do nothing (also tried -L, but got the same error).

Line 49 reads (after some modifications on my part):

CFLAGS = -funsigned-char -Wall -Wno-deprecated-declarations -I src/lua -I src/luasqlite3 -I/sw/include -L/sw/lib -L/usr/local/lib -L/usr/lib -DDEBUGMODE

 

It was the closest thing I could find to what you stated above :unsure:

Link to comment
Share on other sites

Any idea what I should do to fix this?

 

try compiling with no_ttf=1

 

Yes, doing that already. Up to now I've always issued the make command like this:

make no_dumbogg=1 no_ttf=1

 

Since the makefile stated that DUMB, Ogg Vorbis and FreeType2 are optional, I figured I'd go without them for now, just to see if I can get it working.

 

Thanks, Jonck

Link to comment
Share on other sites

Yes, doing that already. Up to now I've always issued the make command like this:

make no_dumbogg=1 no_ttf=1

 

Since the makefile stated that DUMB, Ogg Vorbis and FreeType2 are optional, I figured I'd go without them for now, just to see if I can get it working.

 

Thanks, Jonck

 

I'm not very good in makefiles either, so just making a guess: maybe your font.cpp was compiled withouth no_ttf=1? Try deleting your font.cpp object file (something like font.o, I don't know what it is in MacOS) and recompiling.

Link to comment
Share on other sites

When changing any compilation options (adding/removing 'no_dumbogg=1' etc.), you need to recompile everything (run 'make clean' to remove old object files). Those '__gk' prefixed functions are really from GlyphKeeper library, but this library is included in the sources of the game, so you don't have to install it separately.

 

Also you might try to build the game using SCons, it's supposedly a more advanced build tool which should detect all the dependencies automatically, but its support is still experimental in UFO2000.

 

PS. Does the game build and run when compiled with 'make no_dumbogg=1 no_ttf=1'?

Link to comment
Share on other sites

check the ufo2000 development mailing list archives - if there is a thing like that - there are more detailed instructions of how I got it to start (even made code for a bundle

It was not rejected. You were just asked to clean up the patch a bit and fix some of the potential problems on other platforms, it makes little sense fixing the code for MacOS and breaking it for everything else (maybe conditional compilation could be used or whatever). Also please note, as far as I know, none of current ufo2000 developers has ever seen MacOS and does not even know what this 'bundle' thing is, so the things which seem obvious to you are not that obvious for the others.

 

and a working xcode project but it was kindly rejected)

A problem with any IDE project file is that it needs to be maintained (when adding new source files, introducing extra library dependencies, etc.). If xcode project file gets outdated, people trying to compile the game for MacOS will have even more troubles than they have right now. Having a working makefile (preferably the same for all platforms), should be enough for people just trying to build the game. I'm not saying that we are not going to use that xcode project, we just need to be sure that you are always around to ensure that it works :)

Link to comment
Share on other sites

Why was my post deleted? I didnt flame... at least it wasnt my intention.

Deleting my post caused me to not get notified of replies ... at least I didn't get one.

 

Anyways I get serge's point concerning xcode :)

ufo2000 compiles with everything (including dumb and so on)

- Again check the archives for instructions.

Link to comment
Share on other sites

When changing any compilation options (adding/removing 'no_dumbogg=1' etc.), you need to recompile everything (run 'make clean' to remove old object files). Those '__gk' prefixed functions are really from GlyphKeeper library, but this library is included in the sources of the game, so you don't have to install it separately.

 

Also you might try to build the game using SCons, it's supposedly a more advanced build tool which should detect all the dependencies automatically, but its support is still experimental in UFO2000.

 

PS. Does the game build and run when compiled with 'make no_dumbogg=1 no_ttf=1'?

 

Succes!! :beer:

 

After running "make clean no_dumbogg=1 no_ttf=1" I again ran "make no_dumbogg=1 no_ttf=1" and it compiled without any hickups :)

 

I did notice the "mouse off" thing that Daij Djan mentioned, but that was a relatively minor nuisance, it was so great to be able to play it after so much fuss :D

 

I would like to thank all of you for helping me out so tirelessly and I hope that OS X users will have some benefit from this thread.

 

Kind regards, Jonck

Link to comment
Share on other sites

Succes!!  :beer:

 

After running "make clean no_dumbogg=1 no_ttf=1" I again ran "make no_dumbogg=1 no_ttf=1" and it compiled without any hickups :)

 

I did notice the "mouse off" thing that Daij Djan mentioned, but that was a relatively minor nuisance, it was so great to be able to play it after so much fuss  :D

 

I would like to thank all of you for helping me out so tirelessly and I hope that OS X users will have some benefit from this thread.

Sure, I have pinned this thread. More OS X users are welcome here :)

 

About "mouse off" problem and the others, I still hope that we will find a way to resolve them eventually. Also beware of bugs, as MacOS support is relatively new, it will be naturally somewhat more buggy than version for windows or linux. Try to play some network games and report here if you notice any problems. Theoretically, because of different architectures, we may get some unexpected game state synchronization problems (reported as 'crc errors' by the game) when playing against windows users. But we can never know for sure until we try :)

Link to comment
Share on other sites

Why was my post deleted? I didnt flame... at least it wasnt my intention.

Deleting my post caused me to not get notified of replies ... at least I didn't get one.

Have no idea, I definitely did not delete anything. Might be some bug occured when submitting reply? :huh?:

ufo2000 compiles and runs on OSX 10.3 - NOT on 10.4 though

I managed to compile all the libraries ufo2000 needs but ufo2000 

itself fails to link:

The errors indicated duplicate symbols: libmx.A.dylib conflicts with 

System.dylib

OS: Tiger 10.4.1

Can anybody help here?

Link to comment
Share on other sites

Can anybody help here?

 

 

Since I don't know anything about the software I'm just going to make a quick suggestion. Software that I developed on 10.3 did not compile out of the box on 10.4. Apparently there were significant changes from GCC 3.3 to GCC 4.0 and code that should have compiled and linked didn't. Since 10.4 comes with GCC 3.3 and GCC 4.0 the symlink for g++ can be symlinked to g++3 and the symlink for gcc can be symlinked to gcc-3.3. This should give you a build environment very similar to the 10.3 build environment.

Edited by Slice
Link to comment
Share on other sites

Succes!!  :beer:

Welcome on board :) Did you get to work on 10.4, if so plz help :)

After running "make clean no_dumbogg=1 no_ttf=1" I again ran "make no_dumbogg=1 no_ttf=1" and it compiled without any hickups :)

Get the libs necessary - wrote it to the mailing list - those even compile fine under TIGER

I did notice the "mouse off" thing that Daij Djan mentioned, but that was a relatively minor nuisance, it was so great to be able to play it after so much fuss  :D

The mouse issue drove me crazy ;) I think it is an allegro bug - reported it just in case.

Link to comment
Share on other sites

Can anybody help here?

 

 

Since I don't know anything about the software I'm just going to make a quick suggestion. Software that I developed on 10.3 did not compile out of the box on 10.4. Apparently there were significant changes from GCC 3.3 to GCC 4.0 and code that should have compiled and linked didn't. Since 10.4 comes with GCC 3.3 and GCC 4.0 the symlink for g++ can be symlinked to g++3 and the symlink for gcc can be symlinked to gcc-3.3. This should give you a build environment very similar to the 10.3 build environment.

Works! Ufo2000 compiles with all 'dependencies' (including dumb and freetype)

gcc-3.3 did the trick :)

 

a very simple 'batch file' to make all of it:

-Prior to running it though:

- make sure you run ./configure for some libs. (NOT for allegro though - it worked but crippled allegro for me.)

- assure pathes are correctly set.

-The compilation may fail - you may need to execute 'sudo ranlib %alib%'

If that is the case, manually, do a sudo gcc_select 3.3, and remake ufo2000. Nothing else though. If you manually do a gcc_select, switch back to 4.0 when done... maybe better for the os!?

- I KNOW I could just su, I sudo a lot as OSX per default doesnt enable the root account.

 

# builds ufo2000 with all its dependencies
sudo gcc_select 3.3

#dependencies
cd ../zlib-1.2.2/; make clean; make; sudo make install
cd ../sqlite-3.2.1/; make clean; make; sudo make install
#cd ../lua-5.0.2/; make clean; make; sudo make install #ufo2000 has its own
lua AFAIK
cd ../libpng-1.2.8/; make clean; make; sudo make install
cd ../libvorbis-1.0/; make clean; make; sudo make install
cd ../libogg-1.1/; make clean; make; sudo make install
cd ../hawknl-1.68/src/; make -f makefile.osx clean; make -f makefile.osx;
sudo make -f makefile.osx install
cd ../../dumb-0.9.2/; make clean; make; sudo make install
cd ../expat-1.95.8/; make clean; make; sudo make install
cd ../freetype-2.1.9; make clean; make; sudo make install
cd ../allegro-4.2.0_3b/; make clean; make; sudo make install

#ufo
cd ../ufo2000/trunk/; make clean; make#; sudo make install
sudo gcc_select 4.0

Link to comment
Share on other sites

HawkNL is a phenomenal crossplatform library that is produced by one guy in his spare time.  I wouldn't say that there is horrible support.  Its free software and if there is a problem with it, then one should consider finding the issue and fixing it.  (Thats just my 2 cents worth)

I agree, HawkNL is quite easy to use and I was able to write a lobby server support for ufo2000 in just a week without no prior networking programming knowledge!

 

But it has some problems too. Unfortunatety the user base of this library is too small and it is not so good tested on all the platforms (that MacOS problems prove that). Also it is the library which causes most of the problems to install (that's just statistics, most of user problems are related to this library in linux/unix). That could be probably also caused by a small user base and unavailability of RPMs or whatever packages for different linux distributives.

 

Another problem is the CPU usage on the server side, I think it is nlPollGroup function bug. When setting timeout to anything but 0, the server seemed to ignore all the clients but the first connected. There is a workaround to it, but the server needs to poll the sockets constantly and sleeping for some time. That's not a very nice solution, but it works. The problem was reported to HawkNL author, but he just ignored it. As I was networking programming newbee, probably that was my fault, but I did not get any help :( I don't believe it is not possible to make a server which does not consume CPU resources when there are no data exchange with the clients. I wonder how this can be achieved with HawkNL, but right now I don't feel like touching something that works (ufo2000 server) even though it a bit greedy on CPU resources.

 

That's the first time I reported the problem 'not very politely', but surprisingly it did work and everyone benefited in the end, even Phil (with a MacOS fix added to the makefile) :) I wonder if it is the best way of reporting HawkNL problems... ;)

 

By the way, thanks for helping to resolve MacOS related problems, I you did not show up, we would still have been stuck =b

Link to comment
Share on other sites

The mouse issue drove me crazy ;) I think it is an allegro bug - reported it just in case.

Does it look like this bug: http://www.allegro.cc/forums/view_thread.php?_id=531338 ?

 

I tried registering at the allegro forum to see the movie, but after numerous attempts have still not received a password (presumably my ISP is filtering the messages out as spam or something like that). So I can't be 100% sure, but from the messages in the thread it sure does sound like the thing we're seeing in the OS X build of ufo2000.

Link to comment
Share on other sites

I agree, HawkNL is quite easy to use and I was able to write a lobby server support for ufo2000 in just a week without no prior networking programming knowledge!

 

But it has some problems too. Unfortunatety the user base of this library is too small and it is not so good tested on all the platforms (that MacOS problems prove that). Also it is the library which causes most of the problems to install (that's just statistics, most of user problems are related to this library in linux/unix). That could be probably also caused by a small user base and unavailability of RPMs or whatever packages for different linux distributives.

 

Another problem is the CPU usage on the server side, I think it is nlPollGroup function bug. When setting timeout to anything but 0, the server seemed to ignore all the clients but the first connected. There is a workaround to it, but the server needs to poll the sockets constantly and sleeping for some time. That's not a very nice solution, but it works. The problem was reported to HawkNL author, but he just ignored it. As I was networking programming newbee, probably that was my fault, but I did not get any help :( I don't believe it is not possible to make a server which does not consume CPU resources when there are no data exchange with the clients. I wonder how this can be achieved with HawkNL, but right now I don't feel like touching something that works (ufo2000 server) even though it a bit greedy on CPU resources.

 

That's the first time I reported the problem 'not very politely', but surprisingly it did work and everyone benefited in the end, even Phil (with a MacOS fix added to the makefile) :) I wonder if it is the best way of reporting HawkNL problems... ;)

 

By the way, thanks for helping to resolve MacOS related problems, I you did not show up, we would still have been stuck =b

 

Thanks for the comments. I do appreciate that you have had trouble with this library and I realize that the Mac is not a highly used platform. (I'm not even a mac programmer, and was kinda forced into the job because I have plenty of experience on BSD's) I think Phil has done an excellent job as a one-man team, and i plan on helping out with the project as much as my job allows me.

Link to comment
Share on other sites

Thanks for the comments.  I do appreciate that you have had trouble with this library and I realize that the Mac is not a highly used platform.  (I'm not even a mac programmer, and was kinda forced into the job because I have plenty of experience on BSD's)  I think Phil has done an excellent job as a one-man team, and i plan on helping out with the project as much as my job allows me.

Continuing to discuss HawkNL here is a bit offtopic, but anyway. I surely would like to have HawkNL become a more mainstream library, so the users would have less problems installing and using it. To be honest, I'm really not sure if my problems using HawkNL resulted from my incompetence or HawkNL bugs. Just to clarify things, a simple but fully functional chat server example could probably help to investigate if the excess cpu usage problem (still?) exists, and it would surely serve as a good example for the new users of the library. Current 'clientserver' example does not focus on that aspect.

Link to comment
Share on other sites

  • 1 month later...
Allegro 4.2.0 was just relased, there are some MacOS related fixes in it, including the mouse cursor fix. Could anyone try to compile ufo2000 with this new version of allegro to check if this mouse problem is really gone?
Link to comment
Share on other sites

  • 3 months later...

Hello everybody.

 

I'm new!

 

I found out how to build HawkNL on OS X 10.4.5 PPC.

 

Here's a patch!

 

I'm not exactly sure how to apply the patch, I'm not a diff expert :) I assume it's used with the patch program. Docs available at gnu.org. The diff was made with diff -ru oldhawknldir myhawknldir, in case it matters.

 

For comfort, I symlinked the makefile for my system like so:

hawknl/src/# ln -s makefile.osx Makefile

This way you don't need to specify the --makefile= option every time.

 

I modified the Makefile to use -dynamiclib, as seen previously in this thread. I also added -pedantic to the CFLAGS, mostly out of curiosity. This led me to hack a little in loopback.c - I changed loopback_getNextPort() just a bit, but that's not important.

 

Then, a define in sock.c broke the build. The thing is that socklen_t is actually defined in Mac OS X, contrary to what the code assumes. Changing the definition of typedef int socklen_t so that it doesn't happen on MacOS X is what makes things go.

 

Then, the $DYLD_LIBRARY_PATH needs to be set so the HawkNL tests can be built, as seen previously in this thread.

 

I added

DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/lib:
export DYLD_LIBRARY_PATH

to my ~/.profile.

 

HawkNL itself does not seem to require building with g++-3.3. It seems to work fine with 4.0, the default on MacOS X, since 10.4 at least.

 

The tests build like so:

gcc -lNL sometest.o -o outputBinary

Note that many of the tests need to be built with gcc, not c++ like the HawkNL library itself.

 

Extra noob hints, sprinkled on for free, seasoned developers please disregard:

My intuition is that the -lNL flag makes the linker (-l) look for library "NL" in the $DYLD_LIBRARY_PATH. This is file /usr/lib/libNL.dylib on my machine. (See the pattern?)

 

That's it, I hope, if I'm not forgetting anything.

 

Update: here's my post on the HawkNL board. I'm linking to it here in case there are any updates over there.

Edited by kristleifur
Link to comment
Share on other sites

UFO2000 rev. 1006 from http://lxnt.info/repos/ufo2k/ builds and runs on OS X 10.4 PPC.

 

I removed the -pthread option from the makefile, and built with make no_dumbogg=1. All the libraries required by UFO2000 were obtained from Fink, except for HawkNL.

 

-pthread is not necessary on OS X, I believe. It looks like pthreads are automatically available in OS X.

 

Results:

 

UFO2000 0.7.1006M
Compiled with Allegro 4.2.0 (beta3), MacOS X on 18:18:07 Mar  4 2006

 

The mouse pointer seems a bit weird. I see two pointers, one MacOS pointer and a little purple pointer from UFO2000 itself. They do not move in unison. The purple pointer is the 'valid' one - the one that presses buttons and things.

 

The colors are also rather strange, mostly the transparency. Explosions are a strange mix between the explosion animation and yellow pixellated chessboards. Here's a shot of a guy standing around, looking at his guns:

http://nemendur.ru.is/kristleifur04/ufo2000-1006-osx.png

 

It seems to play OK, btw, with animations animating, guns shooting and guys dying.

Edited by kristleifur
Link to comment
Share on other sites

Thanks for testing the game on MacOS =b

 

Option '-pthread' is not really necessery even in linux, but I had some weird bugs when trying run the game with older versions of valgrind. Seems like all the mutexes and other synchronization primitives used in allegro library did not work at all and everything died horrybly. Scratched my head for a few days before figured that adding this option as a workaround helps. Now valgrind has several new versions released, I'll check if this workaround is still needed.

 

About mouse cursor, as I have already written several posts above, allegro 4.2.0 release has something in its changelog about this, so it might be already fixed. You can try to ask that Fink maintainers to provide an updated allegro package, beta3 is too old.

 

About weird colors, that might be also releted to allegro and a more up to date version might work better. Anyway, please also try a different display settings combinations in ufo2000.ini (fullscreen or windowed/16 or 32-bit color), maybe some of them will look better.

Link to comment
Share on other sites

I'll try to hack together an semi-intelligent makefile, at worst something that requires specification of 'macosx=1' or something similar.

 

Using the release version of Allegro 4.2.0 fixes the mouse cursor problem, at least partially. I still see both the ufo2000 cursor and the system cursor sometimes, but at least they are in sync.

 

About weird colors, that might be also releted to allegro and a more up to date version might work better. Anyway, please also try a different display settings combinations in ufo2000.ini (fullscreen or windowed/16 or 32-bit color), maybe some of them will look better.

The weird colors persist, even with the new Allegro version. Full-screen and windowed does not seem to matter, neither does 16 or 32-bit color.

 

Here are some screenshots.

 

Note that the Snakeman from the original UFO graphics set looks good, but has a pink gun. The homebrewed soldier graphics are off, however. All the unit graphics I've seen drawn from the original XCOM set look correct, but any other units - as well as all weapon graphics, both in the HUD and the battlemap - look wrong.

 

The map popup looks correct. The inventory screen behaves a little weird, it's as if the mouse gets deactivated, and at first glance the UI looked frozen. Esc-ing out of the inventory and back to the game works OK.

 

Also, the fonts are messed up in some places in the screenshots. That only happens if I set F_SMALLFONT = 1. The 'normal' font looks correct, as in the previous screenshots.

 

Things I'll try next:

* Build the latest beta snapshot, 7.1000 instead of the rev. 1006 I got from the SVN repo. Just out of curiosity.

* See if any patches to the Allegro 4.2.0b3 package that I found in fink are missing from the vanilla release of Allegro 4.2.0. final.

* Makefile hacking

 

Anything else I should try?

 

Update: version 7.1000 looks the same.

Edited by kristleifur
Link to comment
Share on other sites

Looks like these are some endian problems with png files loading or blitting sprites. Alpha channel and other colors are swapped, so we see transparent hills and weird colors.

 

Please also check this thread, it contains the sources of our sprite blitting code:

http://www.allegro.cc/forums/thread/571021

 

It uses TGA files (not PNG) in that example, so please compile it and run. If you see normal explosion animation (the same colors as opening explosion.tga in an image viewer), the problem is in PNG loader. If the colors are broken - that's the fault of our sprite engine.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...