Fixing dlopen("libpthread.so")
Bryan Drewery
bdrewery at FreeBSD.org
Thu Feb 12 00:30:24 UTC 2015
On 12/26/2014 10:53 AM, Konstantin Belousov wrote:
> [Long]
> Proposed patch does the following:
[...]
It seems libthr.3 needs to be updated for the dlopen(3) support, to
remove some of r272070. Also note the ordering comment (which I know you
may not be ready to change yet).
> INTERACTION WITH RUN-TIME LINKER
> The libthr library must appear before libc in the global order of
> depended objects.
>
> Loading libthr with the dlopen(3) call in the process after the program
> binary is activated is not supported, and causes miscellaneous and hard-
> to-diagnose misbehaviour. This is due to libthr interposing several
> important libc symbols to provide thread-safe services. In particular,
> errno and the locking stubs from libc are affected. This requirement is
> currently not enforced.
>
> If the program loads any modules at run-time, and those modules may
> require threading services, the main program binary must be linked with
> libpthread, even if it does not require any services from the library.
>
> libthr cannot be unloaded; the dlclose(3) function does not perform any
> action when called with a handle for libthr. One of the reasons is that
> the interposing of libc functions cannot be undone.
As for the dlclose(3) refusing to work on libthr, I cannot find the
supporting code. Where is it?
Thanks,
Bryan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20150211/5d010669/attachment.sig>
More information about the freebsd-arch
mailing list