[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Example in libtool manual gives wrong dependencies w/ automake.
From: |
Nick Bowler |
Subject: |
Re: Example in libtool manual gives wrong dependencies w/ automake. |
Date: |
Thu, 7 Apr 2011 15:33:42 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi Ralf,
On 2011-04-02 10:42 +0200, Ralf Wildenhues wrote:
> * Nick Bowler wrote on Fri, Apr 01, 2011 at 04:04:21PM CEST:
> > I'm working on a project which uses libltdl to load modules, and I've
> > set it up in a manner pretty similar to what's described in the libtool
> > manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5).
> > In that section, the manual recommends to use a weak library interface.
> >
> > However, the example given in the manual does not work because
> > the generated makefile lacks dependencies from libloader.la to
> > libinterface.la's objects.
>
> Indeed. The reference to the internal *_OBJECTS variable is surprising.
> It would be cleaner to have a libfoo_conv.la convenience
> (noinst_LTLIBRARIES) archive that had the same sources as libfoo.la and
> add that to libbar_la_LIBADD.
>
> A patch to fix libtool.texi to this end would be appreciated.
Indeed, a convenience library does at least seem like an improvement
over what's currently in the manual, irrespective of whether the
approach is ideal. I can probably cook up the patch for this when I
have some time.
> One thing that I wonder about is why you actually need the foo code to
> be both in libfoo and libbar. If possible, then code should only ever
> exist in one shared library. (I may be missing details from the
> dlpreopen machinery here now, it's been a while ... feedback as to what
> worked for you appreciated.)
I don't know the answer to this question, either. I haven't actually
gotten everything working, yet: I was just trying out what the manual
suggested and ran into this issue. When/if I get things working I'll
let you know, but for now I've put this issue on the back burner so it
might be a while.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)