> If I change the link line to the following (using libz.la rather than > -L[path to zlib] -lz): > ... > /bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc > +Oentrysched +Odataprefetch +Onolimit -o libpng.la -rpath > /opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo > pngerror.lo pngget.lo pngmem.lo pngpread.lo pngrio.lo pngread.lo > pngrtran.lo pngrutil.lo pngset.lo pngtrans.lo pngwio.lo pngwrite.lo > pngwtran.lo pngwutil.lo /opt/TWWfsw/zlib11/lib/pa20_64/libz.la -lm > rm -fr .libs/libpng.la .libs/libpng.* .libs/libpng.* > /usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o > pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o > pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o > pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64 > -L/opt/TWWfsw/zlib11/lib/pa20_64 /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl > -lm -lc > ... > $ elfdump -L .libs/libpng.sl | grep Rpath > 4 Rpath /opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64
This one looks like a libtool bug in that it outputs duplicate -L options. Of course, you might argue that HP ld shouldn't duplicate the paths either. It appears that all these problems are a result of HP trying to modify their tools from their original SOM idiom to the newer ELF idiom, trying to maintain backwards compatibility rather than starting fresh. I now see a whole bunch of areas where it just doesn't work well. None of these problems will occur with the GNU linker as it supports the rpath option but unfortunately it has other problems. Anyway, I would like to see the basic support added for hppa64. Then, it can be worked out which of the two approaches is better. This also affects ia64-hpux, so I think Steve Ellcey at HP needs to be involved in the discussion. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
