Date: Fri, 10 Feb 2006 19:16:37 -0500 From: Alexander Kabaev <kabaev@gmail.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-current@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: [jakub@redhat.com:Linking against libpthread via -pthread? Message-ID: <20060210191637.374daa37@kan.dnsalias.net> In-Reply-To: <20060210195204.GF2090@dan.emsphone.com> References: <20060210181715.GA21782@troutmask.apl.washington.edu> <20060210193907.GE2090@dan.emsphone.com> <20060210194503.GA10370@troutmask.apl.washington.edu> <20060210195204.GF2090@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_0Vdq_/DfSOrhO6ftAyFY3LC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 10 Feb 2006 13:52:04 -0600 Dan Nelson <dnelson@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 > > >=20 > > > 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. > >=20 > > 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?). >=20 > 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. >=20 > libc_r is still the only threads library that provides reliable %CPU > stats and readable ktrace/truss/strace output afaik. >=20 > --=20 > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@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. --=20 Alexander Kabaev --Sig_0Vdq_/DfSOrhO6ftAyFY3LC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD7SzwQ6z1jMm+XZYRApAOAKDjR+OgueZWJQMs5Rs80yYyQLNuCwCglCn7 ROO0eC7jhYZMvTwKx42kdic= =ez89 -----END PGP SIGNATURE----- --Sig_0Vdq_/DfSOrhO6ftAyFY3LC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060210191637.374daa37>