Compile problems OSX 10.3.9 Allegro 4.2.2

Compile problems OSX 10.3.9 Allegro 4.2.2

dcavanagh

Member #9,981

July 2008

Hi all,

After two days of google-ing and trying different strategies posted here on the forums, I was hoping to get some help compiling allegro on my (admittedly old) g4 powerbook runinng osx 10.3.9.

I'm using the Allegro 4.2.2 stable release.

I have a recent version of Apple's developer tools (XCode 1.5), the latest that will run on 10.3.9. I also read several threads that mentioned that there were also problems with the Quicktime 7.0.1 framework, but I now have qt 7.5 installed, and I am not receiving any errors related to the qt framework.

After following the instructions in docs/build/macosx.txt, the compiling fails when I run make.

I receive the following error:

ld: /usr/lib/gcc/darwin/3.3/libgcc.a(_fixunssfdi.o) illegal reference to symbol: ___cmpdi2 defined in indirectly referenced dynamic library /usr/lib/libgcc_s.1.dylib
/usr/bin/libtool: internal link edit command failed
make: *** [lib/macosx/liballeg-4.2.2.dylib] Error 1

I am a relative newbie to actually compiling source in the terminal (i.e. outside of XCode), so if anyone could explain what's going on I would appreciate it. Or any tips would also be appreciated. From what I can tell, the error is a gcc problem, but I'm kind of a Unix nOOb.

Thanks!

[EDIT] I have figured out the problem, but do not know how to fix it. I need to explicitly include the libgcc_s.1.dylib in the build (OSX does not allow indirect referencing of symbols). How can I ensure the build explicitly includes that file?

vbovio

Member #8,283

January 2007

I'm also interested in this issue, any more ideas ?..

---------------
BovioSoft

dcavanagh

Member #9,981

July 2008

Well, after putzing with it some more, it seems you have to find a way to explicitely include libgcc_s.1.dylib (which is simply an alias to libgcc_s.1.0.dylib)

However, I have no idea what I'm doing with makefiles and this one's pretty complicated, so if anyone with makefile experience could point the way it'd be greatly appreciated.

Peter Hull

Member #1,136

March 2001

You could add -lgcc_s (or maybe -lgcc_s.1) to line 159 of makefile.osx

ifdef STATICLINK
LIBRARIES = $(STATIC_LIBRARIES)
else
LIBRARIES = -framework Cocoa **HERE**
endif

But I'm not convinced that's it; from my own googling it looks like libgcc_s is something to do with gcc 4 and you seem to be building with gcc 3.3. Is there a possibility you've got some objects/libraries that have been built with gcc 4 left over from somewhere.

Can you post a bit more of what the makefile was doing just before the error. Also if you can see the libtool command line can you re-run it with the -v option.

Thanks

pete

dcavanagh

Member #9,981

July 2008

I tried your suggestions with the makefile to no avail, and I also tried -libgcc_s and -libgcc_s.1 as well with no luck. I added the flag -v in the libtool line but that didn't seem to change anything either (I read that it is verbose mode, and should print any commands ld ran, but the output was the same). Thanks for the troubleshooting!

Following is the complete command that runs before the error:

gcc -dynamiclib -compatibility_version 4.2.0 -current_version 4.2.2 -install_name liballeg-4.2.dylib -o lib/macosx/liballeg-4.2.2.dylib obj/macosx/alleg/allegro.o obj/macosx/alleg/blit.o obj/macosx/alleg/bmp.o obj/macosx/alleg/clip3d.o obj/macosx/alleg/clip3df.o obj/macosx/alleg/colblend.o obj/macosx/alleg/color.o obj/macosx/alleg/config.o obj/macosx/alleg/datafile.o obj/macosx/alleg/dataregi.o obj/macosx/alleg/digmid.o obj/macosx/alleg/dither.o obj/macosx/alleg/dispsw.o obj/macosx/alleg/drvlist.o obj/macosx/alleg/file.o obj/macosx/alleg/fli.o obj/macosx/alleg/flood.o obj/macosx/alleg/font.o obj/macosx/alleg/fontbios.o obj/macosx/alleg/fontbmp.o obj/macosx/alleg/fontdat.o obj/macosx/alleg/fontgrx.o obj/macosx/alleg/fonttxt.o obj/macosx/alleg/fsel.o obj/macosx/alleg/gfx.o obj/macosx/alleg/glyph.o obj/macosx/alleg/graphics.o obj/macosx/alleg/gsprite.o obj/macosx/alleg/gui.o obj/macosx/alleg/guiproc.o obj/macosx/alleg/inline.o obj/macosx/alleg/joystick.o obj/macosx/alleg/keyboard.o obj/macosx/alleg/lbm.o obj/macosx/alleg/libc.o obj/macosx/alleg/lzss.o obj/macosx/alleg/math.o obj/macosx/alleg/math3d.o obj/macosx/alleg/midi.o obj/macosx/alleg/mixer.o obj/macosx/alleg/modesel.o obj/macosx/alleg/mouse.o obj/macosx/alleg/pcx.o obj/macosx/alleg/poly3d.o obj/macosx/alleg/polygon.o obj/macosx/alleg/quantize.o obj/macosx/alleg/quat.o obj/macosx/alleg/readbmp.o obj/macosx/alleg/readfont.o obj/macosx/alleg/readsmp.o obj/macosx/alleg/rle.o obj/macosx/alleg/rotate.o obj/macosx/alleg/scene3d.o obj/macosx/alleg/sound.o obj/macosx/alleg/spline.o obj/macosx/alleg/stream.o obj/macosx/alleg/text.o obj/macosx/alleg/tga.o obj/macosx/alleg/timer.o obj/macosx/alleg/unicode.o obj/macosx/alleg/vtable.o obj/macosx/alleg/vtable15.o obj/macosx/alleg/vtable16.o obj/macosx/alleg/vtable24.o obj/macosx/alleg/vtable32.o obj/macosx/alleg/vtable8.o obj/macosx/alleg/cblit16.o obj/macosx/alleg/cblit24.o obj/macosx/alleg/cblit32.o obj/macosx/alleg/cblit8.o obj/macosx/alleg/ccpu.o obj/macosx/alleg/ccsprite.o obj/macosx/alleg/cgfx15.o obj/macosx/alleg/cgfx16.o obj/macosx/alleg/cgfx24.o obj/macosx/alleg/cgfx32.o obj/macosx/alleg/cgfx8.o obj/macosx/alleg/cmisc.o obj/macosx/alleg/cscan15.o obj/macosx/alleg/cscan16.o obj/macosx/alleg/cscan24.o obj/macosx/alleg/cscan32.o obj/macosx/alleg/cscan8.o obj/macosx/alleg/cspr15.o obj/macosx/alleg/cspr16.o obj/macosx/alleg/cspr24.o obj/macosx/alleg/cspr32.o obj/macosx/alleg/cspr8.o obj/macosx/alleg/cstretch.o obj/macosx/alleg/czscan15.o obj/macosx/alleg/czscan16.o obj/macosx/alleg/czscan24.o obj/macosx/alleg/czscan32.o obj/macosx/alleg/czscan8.o obj/macosx/alleg/ccolconv.o obj/macosx/alleg/cadigi.o obj/macosx/alleg/camidi.o obj/macosx/alleg/drivers.o obj/macosx/alleg/hidjoy.o obj/macosx/alleg/hidman.o obj/macosx/alleg/keybd.o obj/macosx/alleg/pcpu.o obj/macosx/alleg/qtmidi.o obj/macosx/alleg/quartz.o obj/macosx/alleg/qzfull.o obj/macosx/alleg/qzmouse.o obj/macosx/alleg/qzwindow.o obj/macosx/alleg/soundman.o obj/macosx/alleg/system.o obj/macosx/alleg/ufile.o obj/macosx/alleg/utimer.o obj/macosx/alleg/uptimer.o obj/macosx/alleg/usystem.o obj/macosx/alleg/uthreads.o obj/macosx/alleg/colconv.o -framework Cocoa -framework Carbon -framework IOKit -framework System -framework CoreAudio -framework AudioUnit -framework AudioToolbox -framework QuickTime
ld: /usr/lib/gcc/darwin/3.3/libgcc.a(_fixunssfdi.o) illegal reference to symbol: ___cmpdi2 defined in indirectly referenced dynamic library /usr/lib/libgcc_s.1.dylib
/usr/bin/libtool: internal link edit command failed
make: *** [lib/macosx/liballeg-4.2.2.dylib] Error 1

Edgar Reynaldo

Major Reynaldo

May 2007

Does this help at all?

http://lists.apple.com/archives/X11-users/2003/Jul/msg00097.html said:

Mac OS X's two-level namespace linker requires more libraries to be specified on the link line than some other linkers. In your case, GnoTime is linking to some library libSomething and libSomething links to libX11. GnoTime also uses XSetIOErrorHandler from libX11. Some linkers allow this to succeed, but Mac OS X doesn't allow symbols to be referenced indirectly through some intermediate library; if you want to use a symbol from a library, you must link to that library directly.

Perhaps there is a lib that is not being linked to that should be?

~~Edit~~
http://www.idevgames.com/forum/showthread.php?t=10150
Perhaps you have multiple versions of the allegro or c libraries installed somewhere. Not sure where to check for these on a Mac.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

dcavanagh

Member #9,981

July 2008

Edgar said:

Some linkers allow this to succeed, but Mac OS X doesn't allow symbols to be referenced indirectly through some intermediate library; if you want to use a symbol from a library, you must link to that library directly.

Yes, I had read that post during my two days of googling . I believe that's why Pete suggested I link directly to that library after the framework linking. Unfortunately that didn't work.

Edgar said:

Perhaps you have multiple versions of the allegro or c libraries installed somewhere. Not sure where to check for these on a Mac.

Good thought - I searched for the libgcc_s.1.dylib files, and my system has two copies - one in usr/lib and one in usr/lib/gcc/darwin/3.3

Not sure if that makes a difference or not. The linker error is definitely pointing to the usr/lib/gcc/darwin/3.3 copy, but that's referencing the library in /usr/lib. That's kind of strange, although as I said, I'm still a bit of a newbie when it comes to this stuff (grew up on XCode, which does it all for you when you start a project in it, so I've never had to deal with this stuff).

Any more thoughts?

Edgar Reynaldo

Major Reynaldo

May 2007

Have you made any progress on getting it to compile? Sorry, sometimes I forget about threads if they don't stay on the Recent Threads list.

Are the two libraries identical files? One is in usr/lib which I am guessing on a Mac is where the libraries available to the system are kept and the other is in gcc/darwin/3.3 which is probably just a copy. Check it out anyway. The gnu diff tool can compare files although there is probably a simpler way to compare them.

Quote:

The linker error is definitely pointing to the usr/lib/gcc/darwin/3.3 copy, but that's referencing the library in /usr/lib.

Not quite, it's trying to link the libgcc.a archive in usr/lib/gcc/darwin/3.3 - but it fails because the libgcc_s.1.dylib hasn't been linked against directly but through another symbol.

error said:

Changing the order of the linking commands may be necessary. You could also try updating your gcc compiler to a newer version but I think it comes down to not having linked against libgcc_s.1.dylib first or earlier in the linking order.

Peter Hull

Member #1,136

March 2001

You shouldn't have to link to that library explicitly; it should be part of the work that gcc does behind the scenes.

I wonder, can you create any kind of .dylib with your current setup? I say this because Allegro's makefile does not do anything clever when linking.

Pete

Edgar Reynaldo

Major Reynaldo

May 2007

I found this thread with the exact same error message (In French)
http://forums.macgeneration.com/developpement-sur-mac/sdl-218091.html
Here's the google languange tools translation into English :
Very Long Url

This is what looks like the solution -
Untranslated :

Quote:

Selectionne le mode deployment
Dans la liste de gauche, clique sur les differentes libraires et dans la liste de droite verifie qu'elles ont toutes la petite case bleue cochée.

Cordialement

Google translation :

Quote:

Select the method Deployment
In the list on the left, click on different booksellers and a list of right they have verified all the little blue box checked.

Best regards

I think the word booksellers there should be libraries instead. I don't have XCode or a Mac either so I hope you know what options they're talking about.

My best guess at the correct translation of the Google translation :

Quote:

Select the Deployment method menu option -
In the list on the left, click on ?alternative ?libraries and in the list on the right verify all the blue option boxes are checked.

This was the last post in the thread where he said he got it to work -

Translation said:

I just change the "Cross-Develop Using Target SDK" Current Mac OS MacOSX10.2.8 (and add the framework in the right place).

Does doing any of these things make any sense to the XCode users here?

Peter Hull

Member #1,136

March 2001

Can you try a quick test - can you download the attached makefile, put it somewhere and run make. It should create an exe called 'greet' that links to a dylib. Does this work for you? Please can you post the output?

Pete

Quote:

Does doing any of these things make any sense to the XCode users here?

As I understand it those instructions are how to build things in XCode, whereas the OP is trying to build from Allegro's makefile.

Edgar Reynaldo

Major Reynaldo

May 2007

Perhaps it is possible that the mistake in the configuration of Xcode is the same thing that is going wrong with allegro's makefile for the Mac. Is there anyone with Xcode that can reproduce the error message by changing their configuration?

Peter Hull

Member #1,136

March 2001

Zut alors! J'ai lu ton link maintenant, et j'ai un autre idée.

The bit where he changes to the 10.2.8 SDK fixes his second error (the illegal reference to symbol) so I don't think it's relevant here.

The thing that might do it is the reference to the Foundation framework (where he says "En cochant le framework Foundation en plus, je n'ai plus l'erreur précédente"). It isn't in dcavanagh's link line and it maybe should be.

So, can you add -framework Foundation into the makefile (where -framework Cocoa is).

Good luck,

Pete

dcavanagh

Member #9,981

July 2008

Sorry, everyone, I was out of town for a week. I'll try your suggestions when I get home tonight...thanks!

[EDIT] Had some time at lunch - here's the output. Worked like a charm.

echo "#include <stdio.h>" > greet.c
echo "#include \"plib.h\"" >> greet.c
echo "int main() {" >> greet.c
echo "printf(\"Hello %s\\n\", pete()); return 0;}" >> greet.c
echo "char* pete(void);" > plib.h
cc -c -o greet.o greet.c
echo "char* pete(void) { return \"Peter\"; }" > plib.c
cc -c -o plib.o plib.c
libtool -v -dynamic -o plib.dylib plib.o
+ ld -arch_multiple -arch ppc -dylib -dynamic -all_load -force_cpusubtype_ALL -no_arch_warnings -ldylib1.o plib.o -o plib.dylib
cc greet.o plib.dylib -o greet

I also tried to add the Foundation framework to the allegro makefile.osx and that did not work either.

It seems there's still an issue with the Allegro makefile and my system.

Is there a way to install Allegro for development on my system without building it on my system? I.e., could someone post or email me the proper files? If that's the case, I'm willing to go that route, because I just want to use XCode to develop allegro programs anyway...I don't really care how Allegro is installed/built on my system, as long as it works.

Peter Hull

Member #1,136

March 2001

When you say 'did not work' was it exactly the same error as before?

I am working on a 'proper' framework for Allegro 4.2 but I haven't finished it yet. Also I can't send you my XCode 2.0 project if you have 1.5 (Thanks, Apple)

I'll think some more but I can't understand why it won't work.

Pete

dcavanagh

Member #9,981

July 2008

yes, the exact same error message as before.

Thanks for your help everyone - I really appreciate all the advice. I'll keep poking around, and if you think of anything else I'll keep an eye on this thread.

If nothing else, I have a much better understanding of using makefiles now!

Edgar Reynaldo

Major Reynaldo

May 2007

Did you copy makefile.osx into the 'makefile' file?

dcavanagh

Member #9,981

July 2008

No, I did not copy makefile.osx into the makefile for Allegro because it includes it.

Is that something I should try? Or do you mean copy the makefile.osx into the makefile that Peter sent?

Edgar Reynaldo

Major Reynaldo

May 2007

I only asked it because on Windows with MinGW, if I run "mingw32-make" it will use the makefile without an extension. I thought perhaps it could be running the wrong makefile from make. I just wanted to check if the correct makefile was being used, that's all, not for you to alter the test makefile Peter posted for you to try earlier.

dcavanagh

Member #9,981

July 2008

Ah, gotcha. Yes, the makefile on osx is automatically included when you run make...