tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fixing libpthread noload, another approach
On Tue, Feb 05, 2013 at 02:58:09AM +0100, Emmanuel Dreyfus wrote:
> 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
> libgthread-2.0.so either
Yeah, I also find it confusing.
> But libgobject-2.0.so depends on glib-2.0.so, and that one contains
> pthread-related stuff:
> $ nm -D /usr/pkg/lib/libglib-2.0.so|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 glib-2.0.so. How do you do
> that?
Basically, define it as weak alias to a function that fails. Same deal
as lib/libc/thread-stub/thread-stub.c.
We should provide at least pthread_join and pthread_condattr_* in libc
as stubs, but for netbsd-6 that doesn't help.
> 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
Almost. libgthread does link against libpthread. From what I understand,
linking it in and calling the init method is supposed to enable
threading inside glib.
> 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.
This would be the alternative to step 1.
> 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.
There won't be a generic solution, since any approach requires at the
very least an audit of the code to see whether it really requires
threading. Just overriding it would otherwise just move from an explicit
early error to much harder to diagnose problems later.
Joerg
Home |
Main Index |
Thread Index |
Old Index