David R. Morrison wrote:
[]
>> /bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -L/usr/X11/lib
>> -Wl,-framework,CoreServices,-framework,ApplicationServices -L/sw/lib
>> -L/sw/lib -L/usr/X11R6/lib -o libgd.la -rpath /sw/lib -version-info
>> 2:0:0 gd.lo gdfx.lo gd_security.lo gd_gd.lo gd_gd2.lo gd_io.lo
>> gd_io_dp.lo gd_gif_in.lo gd_gif_out.lo gd_io_file.lo gd_io_ss.lo
>> gd_jpeg.lo gd_png.lo gd_ss.lo gd_topal.lo gd_wbmp.lo gdcache.lo
>> gdfontg.lo gdfontl.lo gdfontmb.lo gdfonts.lo gdfontt.lo gdft.lo
>> gdhelpers.lo gdkanji.lo gdtables.lo gdxpm.lo wbmp.lo -L/sw/lib -liconv
>> -R/sw/lib -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz
>> gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o
>> .libs/libgd.2.0.0.dylib .libs/gd.o .libs/gdfx.o .libs/gd_security.o
>> .libs/gd_gd.o .libs/gd_gd2.o .libs/gd_io.o .libs/gd_io_dp.o
>> .libs/gd_gif_in.o .libs/gd_gif_out.o .libs/gd_io_file.o
>> .libs/gd_io_ss.o .libs/gd_jpeg.o .libs/gd_png.o .libs/gd_ss.o
>> .libs/gd_topal.o .libs/gd_wbmp.o .libs/gdcache.o .libs/gdfontg.o
>> .libs/gdfontl.o .libs/gdfontmb.o .libs/gdfonts.o .libs/gdfontt.o
>> .libs/gdft.o .libs/gdhelpers.o .libs/gdkanji.o .libs/gdtables.o
>> .libs/gdxpm.o .libs/wbmp.o -L/usr/X11/lib -L/sw/lib -L/usr/X11R6/lib
>> /sw/lib/libiconv.dylib /usr/X11/lib/libXpm.4.11.0.dylib
>> /usr/X11/lib/libXau.6.0.0.dylib /usr/X11/lib/libXdmcp.6.0.0.dylib
>> /usr/X11/lib/libX11.6.2.0.dylib /sw/lib/libjpeg.dylib
>> /usr/X11/lib/libfontconfig.dylib /usr/lib/libiconv.dylib
>> /usr/lib/libz.dylib /usr/lib/libexpat.dylib
>> /usr/X11/lib/libfreetype.dylib /usr/X11/lib/libpng12.0.26.0.dylib -lz
>> -Wl,-framework -Wl,CoreServices -Wl,-framework
>> -Wl,ApplicationServices -install_name /sw/lib/libgd.2.dylib
>> -Wl,-compatibility_version -Wl,3 -Wl,-current_version -Wl,3.0
>> i686-apple-darwin9-gcc-4.0.1: /usr/X11/lib/libpng12.0.26.0.dylib: No
>> such file or directory
Apart from everything else, I think this can also be blamed on libtool.
It translates a simple "-lpng12" which the compiler would perfectly
understand without libtool's "help", into a non-existent
"/usr/X11/lib/libpng12.0.26.0.dylib", and the latter, even when it
exists, is only a symlink to the real file /usr/X11/lib/libpng12.0.dylib
which has an install_name of /usr/X11/lib/libpng12.0.dylib.
So there is no justification whatsoever for libtool to place that
garbage on the gcc command line.
Of course, libtool does not invent this on its own; it takes its wisdom
from the corresponding /usr/X11/lib/libpng12.la file. More precisely, it
takes the last name in the "library_names" line in that file. If
anything, it should take the *first* name in that line, or the "dlname".
And Apple is to blame too, of course. They have no reason to create all
those weird symlinks in /usr/X11/lib that serve no real purpose except
for causing occasional linker crashes. (Remember the libXrandr
catastrophe in 10.5.2? Fortunately, this seems to be fixed in 10.5.3
now, although not by fixing the *.la file, but by creating yet another
superfluous symlink...)
--
Martin
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
