On 2007-04-19 Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * 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? Hello, Because it is the natural thing to do? If one compartmentalized part of the source grows an external dependency, adding the dependency exactly there is simply the natural thing to do. (Otherwise if you choose to re-use only this part somewhere else you are going to forget the dependency for sure. > 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. And that is exactly what goes wrong. It does not put the library dependency in the la file, it puts the library dependency and *its* dependencies in the la file. [ Snip ] >>> 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? I do want liblgnu.la to be linked with against -lgcrypt. I also want libgnutls to be linked against -lgcrypt (because it needs it itself and because it is linked against liblgnu.la.) However I definitily do not want libgnutls to be linked against libgpg-error. libgnutls does (currently) not reference libgpg-error directly. (liblgnu does not either.) It just ends up on the link line because it is an indirect dependency but should not. > 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. I also get that feeling. Perhaps you did miss the initial paragraph in my bug report? | I have just realized that the Debian specific libtool enhancement ^^^^^^^^^^^^^^^ | [...] does not work when libtool convenience libraries | (noinst_LTLIBRARIES) are used. > 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? I agree with you. libm itself does not have any dependencies except libc. However if it did depend on libbar, I would argue that objdump -p src/.libs/libfoo.so | grep NEEDED.\*libbar should be empty, since neither libmysine nor the final product libfoo.so directly use symbols from libbar, the dependency is only an indirect one, pulled in by libtool. thanks, cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
