Re: Fixing -pthreads (Re: ports and -current)

From: Brad Knowles <>
Date: Wed, 24 Sep 2003 13:08:40 +0200
At 7:35 PM -0400 2003/09/23, Daniel Eischen wrote:

>  The applications is free to link to whatever it wants;
>  we're not changing that.  If it wants to link to 1:1
>  libthr or whatever, then it had better be sure to use
>  -lthr because -pthread won't do it regardless of whether
>  it is a NOOP or not.

	It strikes me that the compiler and linker should be able to 
detect -lthr vs. -lpthread vs. -lksethread (or whatever) on the 
command line, and if they see something like that to just DTRT with 
regards to a -pthread as well.

	Contrariwise, if there is a -pthread and no corresponding -lthr, 
-lpthread, or other thread library linkage that is explicitly 
specified, then we should be able to go through pmap.conf and figure 
out what the default "right thing" is that should be done.

	What am I missing?

>  Making -pthread a NOOP _would_ (*) break the application
>  in the link stage; it would be obvious when the application
>  failed to link with lots of unresolved pthread symbols.
>  (*) Unless we want to support LD_PRELOAD being able
>  to change the threads library.

	That would seem to be another reasonable option.

Brad Knowles, <>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
Received on Wed Sep 24 2003 - 03:21:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC