tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fixing libpthread noload, another approach

Joerg Sonnenberger <> wrote:

> So I am still trying to understand WTF the glib design is supposed to
> be. What I am guessing at the moment is that an application is supposed
> to link against libglibthread if it wants to create threads. So the fix
> for glib in this case would be to not use pthread_create as strong
> symbol and/or link against a library just providing it as weak AND
> require libglibthread to link against libpthread.

Um, I just look at it, and it is quite confusing: has -lpthread but reference no pthread_* symbol either

But depends on, and that one contains
pthread-related stuff:
$ nm -D /usr/pkg/lib/|grep pthread
         U pthread_attr_destroy
         U pthread_attr_init
         U pthread_attr_setstacksize
         U pthread_condattr_destroy
         U pthread_condattr_init
         U pthread_create
         U pthread_detach
         U pthread_join

If I understand your plan, you propose to:
1- make pthread_(create|detach|join) weak in How do you do
2- remove -lpthread from, and
I had a look at it, it is not straightforward, but nothing is impossible
with a bunch of patches. The only annoying thing is to maintain them on
the long run
3- create with stubs for pthread_(create|detach|join)
that abort the program, link the DSO to be dlopen() against it. Or add
the stubs to the DSO that is to be dlopen(). Or add them to libc.

IMO the change to ld.elf_so is a better way beacause we do not have to
patch many third party programs. I already encountered the problem with
pam-11 and now with pam-saml/cy2-saml. I know it is probably awaiting
someone in pam-pkcs11, and probably many other places. But at least if
there is another suboptimal plan that works I can go with it. 

Emmanuel Dreyfus

Home | Main Index | Thread Index | Old Index