Re: fixing libpthread noload, another approach

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Julio Merino <julio%meroh.net@localhost> wrote:

> As Alan suggested in 20130126064433.GG1859%apb-laptoy.apb.alt.za@localhost,
> could you please write a document that answers all those questions for
> the various alternatives you are considering

That was done in 1kwym2k.6pdn3w15km16jM%manu%netbsd.org@localhost and the
subsequent discussion. I can sum it up there:

1- we can link with -lpthread programs that are going to dlopen a DSO
linked with -lpthread. This means pushing patches upstream for any
program using dlopen() for third party DSO. These patch working around a
NetBSD specific limitation are not likely to get accepted. At least not
in every program.

2- we can use LD_PRELOAD to add libpthread where needed. This is not
always possible. For instance, dovecot forks to launch the process that
uses PAM (and therefore dlopen), and the environement is not passed to
the child. This could be worked around using a shell-script wrapper for
the child process, but it is not very maintable on the long term.

3- we can remove -lpthread from DSO that do not use threads. This may be
difficult. For instance, liblasso depends on libobject-2.0 and that one
depends on libpthread. And it does because it conainst thread stuff that
liblasso does not use, therefore this is not just removing an unused
-lpthread in ligobject-2.0, but building a thread-stripped
libobject-2.0. This means maintaning a patch set against glib2, another
thing difficult to maintain on the long term

4- we can add functionnality to mutex and condvar libc stubs, so that of
instead being noops, they initialize and set pthread_(mutex|conf)_t
fields. That way we can dlopen libpthread, and its mutex and condvar
implementation can resume with pthread_(mutex|conf)_t fields correctly
set by libc stubs. This will cause a performance hit for programs not
linked with -lpthread and do not use dlopen, with no benefit for them. I
already posted patches for that but I am not convinced this is the
proper way to do it

5- we can have dlopen reporting success at loading libpthread, while in
fact avoid loading it, resolving all its symbol to a runtime error stub.
That way programs that do not use threads can dlopen libpthread and
work, but programs that dlopen libpthread then try to call
pthread_create will fail. This is the patch I posted here and I beleive
this is the best approach.

- 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost