Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Feb 2006 13:23:20 -0500 (EST)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Alexander Kabaev <kan@freebsd.org>
Cc:        freebsd-current@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject:   Re: [jakub@redhat.com:Linking against libpthread via -pthread?
Message-ID:  <Pine.GSO.4.43.0602111311570.11929-100000@sea.ntplx.net>
In-Reply-To: <20060211152627.GA88895@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 11 Feb 2006, Alexander Kabaev wrote:

> On Sat, Feb 11, 2006 at 09:39:08AM -0500, Daniel Eischen wrote:
> >
> > Why?  If one _really_ needs a shared library linked to libpthread,
> > -lpthread will always work.
> >
> > --
> > DE
> >
> Just think for a moment how exactly will your shared library depend
> on a specific symbol version in C or thread libraries if no
> dependencies on libc.so.6 and libpthread.so.2 were recorded in the
> first place? When no -lc or -lpthreed were seen by ld at all?
> The symbol is defined by a name, version and library's SONAME.

Well, so far we want libthr and libpthread to use the same symbols
with the same map name so this can all just work regardless of
which thread library you use.  I can see why this is really,
really, needed for libc where you really want symbol versioning
to work.  I'm just wondering if there is a way for the thread
libraries to do necessary versioning within libc.  Like adding
all the pthread_ interfaces into libc as stubs (we already do
some of them and the thread libraries stuff their functions
into a jump table).  But I see that without actually linking
to a thread library, symbol versioning won't work for the
thread libraries unless we play games with libc or some other
stub library (which then loads the appropriate thread library).

-- 
DE




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0602111311570.11929-100000>