Dago, You should have a look at the related "libtool library file", which name is "<libname>.la". In there, you will have an entry which looks like the following: "dependency_libs='-L ... -l ...' : this is those options which are expanded directly when you build a library using libtool. You can either hack this entry directly to solve your problem... or use LD_OPTIONS !
BTW, it is this entry which is almost everytime responsible of the insertion of the building paths into the RPATH of the binaries we build: we should have an ".la cleaner" script be part of the packages creation process, to remove thatn but this is another topic :-) - Dominique On Sun, 7 Dec 2008 13:03:14 +0100, Dagobert Michelsen <[EMAIL PROTECTED]> wrote: > Hi, > > I'm still working on automated 32/64 bit builds and still encounter > new strange things. This time I have an issue with libtool. This > command is issues during make when comiling > libvorbis/trunk/work/build-isa-amd64/libvorbis-1.2.0/examples > > opencsw# /bin/bash ../libtool --tag=CC --mode=link /opt/studio/SOS11/ > SUNWspro/bin/cc -O -xO3 -xarch=amd64 -I/opt/csw/include - > DUSE_MEMORY_H -xarch=amd64 -L/opt/csw/lib/64 -R/opt/csw/lib/\\\ > $ISALIST -R/opt/csw/lib/64 -o seeking_example seeking_example.o ../lib/ > libvorbisfile.la ../lib/libvorbis.la > > This looks good, but libtool reorders the runpath: > > /opt/studio/SOS11/SUNWspro/bin/cc -O -xO3 -xarch=amd64 -I/opt/csw/ > include -DUSE_MEMORY_H -xarch=amd64 -o .libs/seeking_example > seeking_example.o -L/opt/csw/lib/64 ../lib/.libs/libvorbisfile.so / > root/mgar/pkg/libvorbis/trunk/work/build-isa-amd64/libvorbis-1.2.0/ > lib/.libs/libvorbis.so ../lib/.libs/libvorbis.so /opt/csw/lib/64/ > libogg.so -lm -R/opt/csw/lib/64 -R/opt/csw/lib/\$ISALIST > ld: warning: file ../lib/.libs/libvorbis.so: linked to /root/mgar/pkg/ > libvorbis/trunk/work/build-isa-amd64/libvorbis-1.2.0/lib/.libs/ > libvorbis.so: attempted multiple inclusion of file > creating seeking_example > > Putting -R/opt/csw/lib/64 before $ISALIST is pretty pointless as > $ISALIST then never will be used as the library is found earlier. > Debugging the libtool-shellscript, umh, does not reveal any secrets. > It looks like libtool assembles the runpath dynamically from all > runpathes from libraries the to be linked lib depends on and > than reorders it somehow. If I use LD_OPTIONS I can get it > to work, but I understood from the past discussions that > LD_OPTIONS is a Bad Thing(tm). > > Any libtool experts around who can enlighten me how to do this right? > > > Best regards > > -- Dago > _______________________________________________ > devel mailing list > [email protected] > https://lists.opencsw.org/mailman/listinfo/devel > _______________________________________________ devel mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/devel
