Philip Ashmore wrote:
> 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.
That was never portable. Checking the Makefile for git (which is
the example I have at hand), we find that using functions from
libcrypto requires using -lcrypto even if already passed -lssl, on:
- Mac OS X (Apple ld)
- Windows (MSVC)
- Windows (GNU ld from the MinGW project)
All of those platforms use dynamic linking.
Aside from that, the usual best practice is:
- link explicitly to every DSO providing functions you will be using
- do not link explicitly to DSOs that are needed only as a dependency
of functions you will be using
That way, libraries can change which libraries they link to and more
importantly versions of libraries linked to (which is after all an
implementation detail) without breaking programs that use them. Using
--no-copy-dt-needed-entries has many purposes that as mentioned before
I don't want to get into (if you really want to raise that discussion,
you will have to motivate people --- soliciting information on the
purpose of the option on the upstream binutils mailing list in order
to write documentation might be one way). One of the most compelling
is that it catches programs that violate the best practice mentioned
above.
But I don't think that was what you were talking about --- your
example is not about the usual case but something special. So my
advice is still that it would be better to find another way to do what
you are trying to do.
>> /* GNU ld script */
>> INPUT(-llibtreedb-0.9-bare)
>> INPUT(-lv3c-1.8)
>
> Are linker scripts portable?
No, the "implicit linker scripts" feature is specific to GNU ld.
> Can I use LD_PRELOAD to load a shlib that's a linker script to turn on
> debugging?
Linker scripts and --no-copy-dt-needed-entries are build-time
facilities. At run time you can still use the same LD_PRELOAD tricks
you are used to.
[...]
> 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
That means that anyone using pkg-config to link to libtreedb won't run
into this problem, right? You control what goes in pkg-config --libs
output (it certainly isn't supposed to list the dependencies), so this
can be a good and portable way to allow apps to conveniently link to
both libtreedb-bare and v3c when using both APIs.
But thinking about it more, I suspect that is not what you are looking
to make happen. Instead, if I understand correctly, the intent is as
if you had two libraries of PIC code:
libtreedb-0.9-bare
libv3c-1.8
and then linked them together to make libtreedb-0.9.so and linked
libv3c-1.8 alone to make libv3c-1.8.so --- except that to save memory,
the text of libtreedb-0.9 is not supposed to duplicate libv3c.
Linking libtreedb against libv3c and populating it with some aliases
to re-export the latter's functions might be an okay way to make it
happen. I admit I find this example a little weird --- why shield
users from the knowledge of whether they are using functions from the
libv3c API?
[...]
> Sorry If I come across as confused, maybe I don't get it.
I'm quite willing to believe there are documentation bugs lurking.
Thanks for your work.
Regards,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
