Re: [jakub_at_redhat.com:Linking against libpthread via -pthread?

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_at_allantgroup.com