Date: Fri, 10 Feb 2006 13:52:04 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: [jakub@redhat.com:Linking against libpthread via -pthread? Message-ID: <20060210195204.GF2090@dan.emsphone.com> In-Reply-To: <20060210194503.GA10370@troutmask.apl.washington.edu> References: <20060210181715.GA21782@troutmask.apl.washington.edu> <20060210193907.GE2090@dan.emsphone.com> <20060210194503.GA10370@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Feb 10), Steve Kargl said: > On Fri, Feb 10, 2006 at 01:39:08PM -0600, Dan Nelson wrote: > > In the last episode (Feb 10), Steve Kargl said: > > > Some background information: I routinely build GCC mainline on > > > i386-*-freebsd and amd64-*-freebsd. GCC mainline is introducing > > > OpenMP support. When libgomp.so.1 is built, the compiler is > > > given the -pthread option throughout the construction of > > > libgomp.so.1. However, a "ldd libgomp.so.1" shows no dependence > > > on libpthread.so.2 > > > > There was a discussion about this back when the default switched > > from libc_r to libpthread, and I think the consensus was that > > shared libraries should never record dependencies against threads > > libs, which means you have to add -pthread to the link line when > > building the final executable. This avoids problems where an > > executable links to three shlibs, one library is linked to libc_r, > > one's linked to libkse, and a third is linked to libpthread. > > Does this still apply with the symbol versioning that was committed > some weeks (months?) ago? Additionally, I thought libc_r is > deprecated in FreeBSD-current (has it been moved to the attic?). I think symbol versioning only helps if you want to provide multiple compat wrappers for a single symbol depending on the age of the calling program. It won't help two libraries that both want to provide the same public symbols but have different internal ABIs cooperate. libc_r is still the only threads library that provides reliable %CPU stats and readable ktrace/truss/strace output afaik. -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060210195204.GF2090>