Kevin Horton wrote: > lzo2-2.02-1 fails to compile on 10.5 Intel: > > Making all in lzotest > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I.. -I/sw/include - > DLZO_HAVE_CONFIG_H -DLZO_USE_ASM -g -O2 -c lzotest.c > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L/sw/lib -o > lzotest lzotest.o ../src/liblzo2.la > mkdir .libs > gcc -g -O2 -o .libs/lzotest lzotest.o -L/sw/lib ../src/.libs/ > liblzo2.dylib > Undefined symbols: > "_lzo1y_decompress_asm", referenced from: > _compress_database in lzotest.o > _compress_database in lzotest.o [etc]
I get the same, and at least at first glance this looks very much like a bug in /usr/bin/ld. When creating the dynamic liblzo2.dylib, it does not place these symbols inside, although they are present in the object files constituting the dylib. If you replace, on the above libtool command line, the dylib by the static lib (for example by editing liblzo2.la and adding liblzo2.a at the end of the library_names line), then the command goes through, and the tests are completed successfully. I cannot reproduce the bug easily outside of lzo2, because these object files are compiled from very special assembler code and this may play a role in triggering the bug, but at least with the files from the lzo2 build directory, you can reproduce the problem: Take one of the object files like lzo1y_s1.o and link it as a dylib, and you will see that its one and only symbol disappears: costabel% /usr/bin/ld -dylib -o libfoo.dylib .libs/lzo1y_s1.o costabel% nm .libs/lzo1y_s1.o 00000000 T _lzo1y_decompress_asm 00000000 T lzo1y_decompress_asm costabel% nm libfoo.dylib 00000000 t __mh_dylib_header -- Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fink-users mailing list Fink-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-users
