[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fixing libpthread noload, another approach
Joerg Sonnenberger <joerg%britannica.bec.de@localhost> 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:
libgobject-2.0.so has -lpthread but reference no pthread_* symbol
But libgobject-2.0.so depends on glib-2.0.so, and that one contains
$ nm -D /usr/pkg/lib/libglib-2.0.so|grep pthread
If I understand your plan, you propose to:
1- make pthread_(create|detach|join) weak in glib-2.0.so. How do you do
2- remove -lpthread from glib-2.0.so, gobject-2.0.so and gthread-2.0.so.
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 libfakepthread.so 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.
Main Index |
Thread Index |