[Top][All Lists]
[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}
- Linking against indirect dependencies, Szombathelyi György, 2004/05/24
- Re: Linking against indirect dependencies, Albert Chin, 2004/05/24
- Re: Linking against indirect dependencies, Szombathelyi György, 2004/05/25
- Re: Linking against indirect dependencies, Albert Chin, 2004/05/25
- Re: Linking against indirect dependencies, Szombathelyi György, 2004/05/26
- Re: Linking against indirect dependencies, Bob Friesenhahn, 2004/05/26
- Re: Linking against indirect dependencies,
Alexandre Oliva <=
- Re: Linking against indirect dependencies, Szombathelyi György, 2004/05/29
- Re: Linking against indirect dependencies, Alexandre Oliva, 2004/05/29
- RE: Linking against indirect dependencies, Howard Chu, 2004/05/29
- Re: Linking against indirect dependencies, Szombathelyi György, 2004/05/31
- Re: Linking against indirect dependencies, Scott James Remnant, 2004/05/26
- Re: Linking against indirect dependencies, Szombathelyi György, 2004/05/27
Re: Linking against indirect dependencies, Szombathelyi György, 2004/05/26