* Andreas Metzler wrote on Wed, Apr 18, 2007 at 08:16:56PM CEST:
> On 2007-04-17 Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > * Kurt Roeckx wrote on Sat, Apr 14, 2007 at 04:01:46PM CEST:
>
> >> See
> >> http://www.mail-archive.com/[EMAIL PROTECTED]/msg08136.html for a possible
> >> way to solve this.
>
> >> Anyway, this is going to require some work to really solve.
>
> > And anyway it is wrong! You are misunderstanding the very concept of
> > convenience archives. There is *no* indirection that you can take
> > advantage of. All objects of the convenience archive will be included
> > as they are in the library that they end up in. Thus, this library will
> > *explicitly* depend upon all symbols that are referenced from those
> > objects.
>
> hmm. There are a couple of projects that use convenience libraries
> simply as a way to structure the source in different directories
> without implying different linkage semanthics.
Which is fine. But why are they adding library dependencies on the
convenience archives then? Convenience archives are not shared
libraries, they do not need dependency information; think of them as a a
short name for a bunch of object files. The only reason to add library
dependencies is to tell libtool: please, when I ever subsume this bunch
of objects (convenience archive) into a real shared library, remember
for me to also add this library dependency to the real shared library;
because the object files that will be part of it need that library. And
libtool remembers by putting the library dependency into the
libconvenience.la file.
> The libtool manual lists this as a common usage scenario:
> | This technique is often used to overcome GNU automake's lack of
> | support for linking object files built from sources in other
> | directories, because it supports linking with libraries from other
> | directories. This limitation applies to GNU automake up to release
> | 1.4; newer releases should support sources in other directories.
> [...]
>
> > Trying to remove deplibs from this list is like saying: while I said a
> > minute ago that I need these libraries, now I am saying that I don't
> > need them. It's nonsensical.
>
> Eh, no. I was saying that I was going to directly reference symbols
> from and was needing *libgcrypt*. And now, at final link time libtool
> is linking stuff as if I had been saying: "I am needing and directly
> referencing symbols from libgcrypt *and* *its* dependencies."
You are implying some sort of indirection here, which happens when you
have shared library interdependencies. But please note that this simply
does not happen with convenience archives; it can not, by design.
> > Such a patch will not find its way into
> > upstream GNU Libtool.
>
> > If you want less libs linked against, them simply remove them from the
> > link line when you _create_ the convenience archives. They won't mind.
>
> It would probably work for gnutls and if this is indeed not a
> hotfix that will break horribly on strange libtool supported archs
> I'll try to push it upstream.
Sure, but at least I will give you the same answer there, unless you can
somehow convince me of your case; maybe I've still not understood it.
As far as I can see:
Bugs 405239 and 347650 are two different issues from a Libtool POV.
The former is a Libtool limitation (it doesn't handle -Wl,--as-needed
correctly), while the latter is merely a user misunderstanding in what
should be happening. If you don't want libgnutls to depend on
libgcrypt, then why is -lgcrypt added to the link line of liblgnu.la?
liblgnu.la is nothing more than a shorthand for some objects that all
end up in libgcrypt. If those objects need symbols from libgcrypt,
then it's only the right thing to do of libtool to put libcgrypt.so.N
in DT_NEEDED of liblibgnutls.so. Conversely, if those objects do not
reference any symbol from libgcrypt, then adding -lgcrypt to the link
line of liblgnu.la in the first place is the bug that needs fixing.
I sense that we are talking past each other all the time. But also I
don't see how I can explain things any differently. Maybe let's try
with a simple example project: I want a shared library libfoo, and it
will collect some objects from a convenience archive. For my
convenience, I'll use the libtool feature of transporting library
dependency information from the convenience archive:
--- snip example ---
mkdir src lib
cat > src/foo.c <<\EOF
extern double mysine (double);
double foo (double x)
{
return mysine(x);
}
EOF
cat > lib/mysine.c <<\EOF
#include <math.h>
double mysine (double x)
{
return sin (x);
}
EOF
: ${CC=gcc}
libtool --mode=compile --tag=CC $CC -c lib/mysine.c -o lib/mysine.lo
libtool --mode=compile --tag=CC $CC -c src/foo.c -o src/foo.lo
# Create the convenience archive:
libtool --mode=link --tag=CC $CC -o lib/libmysine.la lib/mysine.lo -lm
# Create a shared library that uses the convenience archive:
libtool --mode=link --tag=CC $CC -o src/libfoo.la -rpath \
/usr/local/lib src/foo.lo lib/libmysine.la -no-undefined
--- snip end example ---
If I understand you correctly, then you argue that after this sequence,
objdump -p src/.libs/libfoo.so | grep NEEDED.\*libm
| NEEDED libm.so.6
should produce empty output. My counter argument is that libm *is* a
direct dependency of libfoo, not an indirect one:
nm src/.libs/libfoo.so | grep sin
| 0000000000000700 T mysine
| U sin@@GLIBC_2.2.5
simply because, as shared entity, no such thing as libmysine exists;
only libfoo, and it depends on libm. Which part of this is unclear,
and in which way does this differ from the usage case you're talking
about?
Cheers,
Ralf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
