This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] BZ #5784: Build libpthread.a with ld -r


On Fri, Sep 07, 2012 at 10:06:00AM +0200, Andreas Schwab wrote:
> Roland McGrath <roland@hack.frob.com> writes:
> 
> >       There is a further wrinkle here, the possibility of what might be
> >       termed "dynamic static threadedness".  That is, a program linked
> >       without -lpthread might use dlopen (or equivalent via NSS modules
> >       or whatnot) to load libpthread.so (or another DSO that depends on
> >       it), and then be able to create a thread.  The existing scheme
> >       doesn't account for this possibility, and I am not aware of anyone
> >       having complained, so perhaps nobody actually cares.
> 
> This case has always been rejected as unsupported, ie. if you ever
> create threads you must link main against -lpthread.

I think this decision should be revisited. It should be possible for
third-party libraries to use threads as an implementation detail,
without the main program having to know or be aware of that
implementation detail. Consider for example a main program that uses
loadable modules for different communication protocols, output device
choices, or similar. As these modules are part of the program's
design, it should specify whether they're allowed to use threads
themselves. However, suppose one of the modules (not distributed with
the application, but developed for use with it by a third party)
depends on an existing third-party library for implementing its
functionality -- for example an output module depending on libSDL or a
protocol module depending on some system-installed library that uses
threads.

Now, you have a situation where thread support ends up getting
dynamically loaded. You can say this is an unsupported usage, but each
individual step/decision by the various parties involved was itself
reasonable. The "unsupported" situation only arises when they're seen
in light of each other. I see this as a design bug.

An easy fix would be making libdl depend on libpthread...

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]