Re: Fixing -pthreads (Re: ports and -current)

[Mostly trying to stay out of this thread, but I must comment at
 least on this point.]

On Wed, Sep 24, 2003 at 11:01:01AM -0400, Daniel Eischen wrote:
> On Wed, 24 Sep 2003, Scott Long wrote:
> > Daniel Eischen wrote:
> > >   o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that
> > >     are not dependent on a particular threads library, but will use
> > >     whatever threads library the application uses (i.e., you want mplayer
> > >     to use libpthread and ogle to use libthr).
> > 
> > I'm a big advocate of using libmap to deal with this.
> 
> It isn't clear that libmap can deal with libraries that are
> linked to one specific threads library, and how libmap'd
> applications work.  If mplayer is libmap'd to libthr,
> ogle is libmap'd to libpthread, and both are linked to
> libGL which is linked to libc_r, what happens?
> 
> At the least, -pthread should be a NOOP when building
> shared and dynamic.

While libmap is a very neat hack and very useful, it is indeed
a hack and I do not think it should be the primary method of
determining what libraries to load.  The mere existance of a
libmap.conf file means additional file opening and parsing every time
a dynamically linked executable is loaded; as well as one or more
string searches/substitutions for every dynamic object name that rtld
encounters (not just thread libraries).

I believe that we should be able to make decisions at link time and at
run time.

At link time, either (a) I want *this* threaded library damnit, or (b)
choose a threaded library at run time, with (b) being the default.
Choosing (a) probably allows you to shoot your foot by mixing
threading libraries, but it may also allow you to use `extensions'
that one threading library might provide but not another.

At run time (if (b) was chosen at link time): use *this* threaded
library.  By what mechanism?  I imagined that there could be a library
(say libpthread :-P) that made the decision and loaded the *real*
threading library and forwarded or fixed-up thread-related functions.
A degenerate-but-simple implementation might be a symlink.

This seems to be more-or-less what GCC developer Loren James Rittle
<rittle_at_latour.rsch.comm.mot.com> had in mind when he posted the
following suggestion to freebsd-threads some weeks back:

  Thank you for considering these words.  BTW, wouldn't it be cooler
  if (example only):
  
  -pthread (whatever the system default)
  -pthread=1 (1 process, aka -lc_r)
  -pthread=1:1 (1 process per thread, aka -lthr)
  -pthread=M:N (M threads in N processes, aka -lkse)
  -pthread=late/weak (perhaps not good ELF form, link against a stub to
  which all POSIX thread libraries on FreeBSD must conform, do not
  record the dependency ala FreeBSD4 default for -lc; or that does it in
  a weak manner en mass such that binding is deferred to the final
  selection made at a final link time)

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME      . FreeBSD UNIX       . Heimdal
nectar_at_celabo.org . jvidrine_at_verio.net . nectar_at_freebsd.org . nectar_at_kth.se