libtool
[Top][All Lists]
Advanced

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

Re: Linking against indirect dependencies


From: Alexandre Oliva
Subject: Re: Linking against indirect dependencies
Date: 28 May 2004 04:27:43 -0300
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

On May 26, 2004, Bob Friesenhahn <address@hidden> wrote:

> It also depends on libtool being 100% accurate in determining if a
> library is a static library or a shared library since static
> libraries don't support library dependencies.

And there's another problem.  When libtool passes -ldependency in the
command line, the linker will look for libdependency in the
directories where it looks for libraries (-L).  If libdependency is
only brought in by another shared library that has it in DT_RPATH,
libdependency will be looked for in the --rpath-link search path, and
it will have to be a shared library, i.e., static libs will be
ignored.

Now consider the following scenario:

- libfoo.la is linked with libdep.la, but libdep.la was PIC and
  static-only.  Both are installed.

- libdep is rebuilt as both static and shared, and reinstalled.

- program links with libfoo.la, using symbols from libdep.la that
  weren't brought into libfoo.la

- libtool sees libdep.la is available as a shared lib, so it drops it
  from the link command.  Link fails because libfoo.so doesn't bring
  in libdep.a.

The only way to avoid this sort of problem would be to annotate
libfoo.la with some indication that libdep.la was static-only at the
time libfoo.la was created, as opposed to attempting to detect what
kind of lib it is at the time libfoo.la is linked into something else.

I.e., for libraries that are built as both dynamic and static, libtool
would have to keep two dependency lists, one for the dynamic version,
and one for the static version, such that the dynamic dependency list
doesn't contain dependencies that are shared libraries.

I think it can be made to work, but it's going to be a significant
amount of work, and there are probably some additional problems that
I haven't thought of.  Risky...

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   address@hidden, gcc.gnu.org}
Free Software Evangelist  address@hidden, gnu.org}




reply via email to

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