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>