Re: How does libtool decide which so to link against?

2010-10-25 Thread Mike Frysinger 
On Mon, Oct 25, 2010 at 4:12 PM, Giles Anderson wrote:
 I have upgraded Boost and find that I have to re-link my own executables.
 Should I have to? I dont really want to.

complain to the boost developers for not being ABI compatible (same
SONAME).  or manually keep the old SONAME on your system.  either way,
libtool is doing the right thing.

 g++ -DHAVE_CONFIG_H -I. -I.  -I/home/gander/include   -Wall -O3 -m64 -mtune=k8
 -MT gadirs-gadirs.o -MD -MP -MF .deps/gadirs-gadirs.Tpo -c -o gadirs-gadirs.o
 `test -f 'gadirs.cpp' || echo './'`gadirs.cpp
 mv -f .deps/gadirs-gadirs.Tpo .deps/gadirs-gadirs.Po
 rm -f gadirs
 /bin/sh ./libtool --tag=CXX   --mode=link g++  -Wall -O3 -m64 -mtune=k8 -
 L/home/gander/lib64  -o gadirs gadirs-gadirs.o -lboost_filesystem

the linker takes care of expanding -lboost_filesystem into the
specific SONAME instance on your system.

 Is there a way to force it to link against the link name?

not really if you want to do the right thing

 Isnt that what its there for?

no
-mike

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does libtool decide which so to link against?

2010-10-25 Thread dherring 
Giles Anderson wrote:
 I have upgraded Boost and find that I have to re-link my own executables.
 Should I have to? I dont really want to.

Boost API changes generally involve more than a simple relink.  Their data
structures and templates frequently change, often for bugfixes.  In fact,
many boost libraries are header-only.  I would recommend a full make clean
to remove old object files and do a full rebuild.

The alternative is to follow Mike's advice and somehow preserve the old
shared object files.  Since Boost itself doesn't have many external
dependencies, this might not be difficult.

- Daniel


___
http://lists.gnu.org/mailman/listinfo/libtool