automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Example in libtool manual gives wrong dependencies w/ automake.


From: Ralf Wildenhues
Subject: Re: Example in libtool manual gives wrong dependencies w/ automake.
Date: Sat, 2 Apr 2011 10:42:04 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hello Nick,

* 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.

>  Here's a simplified and complete
> version of the example in the libtool manual:
> 
>   % cat >Makefile.am <<'EOF'
>   lib_LTLIBRARIES = libbar.la libfoo.la
> 
>   libfoo_la_SOURCES = foo.c
> 
>   libbar_la_SOURCES = bar.c
>   libbar_la_LDFLAGS = -weak libfoo.la
>   libbar_la_LIBADD  = $(libfoo_la_OBJECTS)
>   EOF

>   % ./configure -q && make
>     CC     bar.lo
>     CCLD   libbar.la
>   libtool: link: `foo.lo' is not a valid libtool object
>   make: *** [libbar.la] Error 1
> 
> Looking at the generated Makefile.in, we see this is because libbar.la
> doesn't have any dependency on foo.lo.  We can add it to the
> Makefile.am:
> 
>   libbar_la = libbar.la
>   $(libbar_la): $(libfoo_la_OBJECTS)
> 
> and now it will build.  So, should automake support the example in the
> libtool manual, or does the libtool manual need to be fixed?  If the
> latter, is the above workaround a good one?

I see several workarounds.  The one I described above is clean.
Another would be to compute libbar_la_DEPENDENCIES manually, e.g.:
  libbar_la_DEPENDENCIES = $(libfoo_la_OBJECTS)

In a real-life situation, there are other dependencies, so you'd prefer
to use
  EXTRA_libbar_la_DEPENDENCIES = $(libfoo_la_OBJECTS)

so automake will still compute libbar_la_DEPENDENCIES
(available only in git Automake, will be in 1.12; sorry).

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.)


As to whether automake should be able to look through $(*_OBJECTS)
references in _LIBADD and add them to _DEPENDENCIES: yes that too
seems like a viable idea.  'info Automake "Program and Library
Variables"' is currently vague about this case (but it can be, since
_OBJECTS are supposed to be internal details).

So there really are two issues here, one in libtool.texi and one in
Automake.  Thanks for reporting them.

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]