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-threads/attachments/20150211/5d010669/attachment.sig>


More information about the freebsd-threads mailing list