On 09/06/11 05:53, Jonathan Nieder wrote:
Why would libtool follow the static-link model when linking to a DSO?
See<http://bugs.debian.org/191425>. If you disagree with the
reasoning mentioned in that bug and the bugs it is merged with, that
would be a libtool (behavior or documentation) bug.
According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191425#10
Yes, this is a known libtool bug. It is trying to link your program against
all of the dependent libraries of librrd, even though this is unnecessary,
and indeed, strongly discouraged.
So since then, knowing what shared libraries the library you're linking to has
become a
good thing(TM)?
If I were statically linking to libtreedb, libtool would provide all the
archives, even the
indirect ones, through the .la file.
The point I was making about libtool following the static link model is that if
ld behaviour
changed then libtool should be changed too, to list all shared libraries.
I know that libtreedb.so, or one of its dependants, exports needed symbols.
Whether I link
directly or indirectly, that symbol will end up in the address space of the
executable.
A single point of reference - change the .la file name, change the
implementation.
If you disagree with --no-copy-dt-needed-entries being the default
behavior for ld, I don't know what to tell you. Maybe you could
install a wrapper that passes --copy-dt-needed-entries, though that
won't help other Debian or Fedora users build your software. The
rationale for the change is well documented elsewhere.
Maybe binutils should gain a NEWS.Debian.gz file explaining this to
help people upgrading.
As for the original use case that motivates this: perhaps making
/usr/lib/libtreedb.so a linker script would work for you. For
example:
/* GNU ld script */
INPUT(-llibtreedb-0.9-bare)
INPUT(-lv3c-1.8)
Are linker scripts portable?
Can I use LD_PRELOAD to load a shlib that's a linker script to turn on
debugging?
That's what the debugging versions do, by the way.
Sorry to be the bearer of bad news, and hope that helps.
Regards,
Jonathan
I'm sorry to be the one to highlight what appears to be a cognitive gap.
I'm also quite sure that I'm not the only one who writes software that links
indirectly
to symbols, as a way of managing complexity.
Indeed the only entity this approach appears to save work for is the linker!?!
Or am I getting it wrong andnowcomplexity is a good thing(TM)?
Even pkg-config lists the libraries a package depends on
pkg-config --libs v3c
returns -Wl,-rpath -Wl,/usr/lib -lpthread -lv3c-1.8 -luuid
How is this different? Is this wrong too?
Sorry If I come across as confused, maybe I don't get it.
Philip
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
