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

[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

Re: libtool, llvm-gcc, failing C++ exceptions

[dherring]

Bob Friesenhahn wrote:
 While it has not been proven yet, I am suspecting that the failing C++
 exceptions have something to do with the way that libtool links these
 modules.

 Does anyone have ideas about this?

Do all exceptions fail, or just some exceptions?

For example, does something like the following work?

bool handled=false;
try { throw 100; /* or a type local to this compilation unit */ }
catch(int x) { handled=true; }
catch(...)
{
  handled=true;
  assert(false); // should be handled earlier
}
assert(handled);

Many systems catch exceptions based on the address of a symbol that gets
generated with the class destructor; that's caused all my problems when
passing exceptions between libraries.

- Daniel



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

Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

[dherring]

Mike wrote:
 On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote:
 On Tue, 25 Aug 2009, Mike Frysinger wrote:
  Relying on the OS's implicit dependency features seems to be an
  approach which is fraught with peril.
 
  why ?

 When viewing the issue through Linux package-maintainer spectacles
 everything looks pretty straightforward since the environment and
 packages are well managed and tested prior to deployment.  Any
 failures can be usefully corrected.  Libraries are carefully built
 with well-managed partial dependency lists.  If you consider the case
 where someone installs and builds everything from a random collection
 of source packages on a random Linux release, then the situation is
 different.

 This issue has some up oodles of times.  Obviously there is a good
 reason for the complaints (Linux equivalent of DLL hell) but the
 solution in libtool needs to be assured to work everywhere, and not
 just on well-managed well-manicured recent Linux.

 the dll hell issue you refer to really doesnt have much (anything?) to
 do
 with libtool.  that's a binary package issue.

 making the code use reduced library sets for only linux targets is fine by
 me.
 libtool already has plenty of target-specific code based on the quality of
 library handling.


I think the scope of the problem is more devious than you imagine.

Example:
- install libA to /odd/lib/libA.so
- configure libB with /odd/lib/libA.so
- install libB to /odd/usr/lib/libB.so
- configure App with libB in /odd/usr/lib/libB.so
- compilation of App fails since the linker can't find libA.so

Libtool's dependency lists would have told the linker where libA was
installed.  Many people follow this sort of pattern on shared filesystems.

Later,
Daniel



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

Re: C++ Plugins and virtual destructors.

[dherring]

Ralf Wildenhues wrote:
 * Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET:

 Here's a relevant post from the GCC list; it mentions how to work around
 some dlopen difficulties (including RTTI, exceptions, custom
 new/delete).
 http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html

 Thanks for this link.  FWIW, I could not easily see why RTLD_NOW should
 be needed.  If it is, there's an opportunity to extend libltdl's advise
 API for this flag.

I don't think RTLD_NOW is strictly needed.  Instead, it forces everything
(including RTTI and exception class constructors) to resolve correctly
before dlopen succeeds.  If you're trying to catch exceptions, its
probably unnerving to get an unresolved symbol error that only occurs when
you try to throw the exception...  Always using dlopen(RTLD_NOW) should
prevent such gotchas.

- Daniel




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

Linking a lib with different shared and static names

[dherring]

Hi,

I'm trying to link to a library that uses different names for the static
and shared versions.

Example: libABC.so and libABCz.a

Can someone suggest a way to express this to libtool?  Just passing -lABC
fails for static links; -lABCz does the wrong thing on dynamic links.

Thanks,
Daniel




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