Re: fixing libpthread noload, another approach

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

Martin Husemann <martin%duskware.de@localhost> wrote:

> You point out the real bug pretty prominently here, don't you?
> What is it using libgobject for? Can that be split out in a separate binary
> (i.e. to run UI configuration dialogs or whatever, but leave the real PAM
> module untainted)?

Take liblasso, which is something perfectly relevant to be used by a PAM
module. It depends on libgobject, mostly for g_hash, g_list and g_slist,
which seems quite reasonable. 

The problem is thatlibgobject also embed thread-related stuff, but are
you going to tell GNOME people what features they should fold in their
libaries because of 

> Your suggestion, overall, returns the state to something similar than we
> had before - random runtime failures. 

Not quite. Current situation is silent failure of dlopen (unless logs
are correctly configured) for:
- legitimate use, as in the liblasso example
- buggy sitation where pthread_create would be attempted later.

My patch turns it into:
- legitimate use works as it did before
- buggy situation (pthread_create call) aborts reliabily at runtime. 

And as proposed in another message, if we are going to abort the
program, we could openlog/syslog before to make sure the errors makes it
to the log, that will not harm the program.

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