On Fri, 10 Feb 2006 13:52:04 -0600 Dan Nelson <dnelson_at_allantgroup.com> wrote: > 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 > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe_at_freebsd.org" No. The change to link in libc by default and libpthread with -pthread are inthe works and will be committed shortly. There is not way around this if we want working versioned libc and libpthread in our system. -- Alexander Kabaev
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:52 UTC