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 <> 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

Yeah, I also find it confusing.

> 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
> 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, 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

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 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.


Home | Main Index | Thread Index | Old Index