Date: Tue, 8 Jun 2004 14:03:53 -0400 From: Charles Swiger <cswiger@mac.com> Cc: freebsd-ports@FreeBSD.org Subject: Re: RFC: [Long] Change PTHREAD_LIBS to -pthread for -CURRENT Message-ID: <33E67F1E-B976-11D8-8148-003065ABFD92@mac.com> In-Reply-To: <200406081817.43175.michaelnottebrock@gmx.net> References: <1086673141.18374.35.camel@shumai.marcuscom.com> <200406081020.48658.michaelnottebrock@gmx.net> <20040608084115.GC3604@freebsd3.cimlogic.com.au> <200406081817.43175.michaelnottebrock@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 8, 2004, at 12:17 PM, Michael Nottebrock wrote:
> On Tuesday 08 June 2004 10:41, John Birrell wrote:
>> The reason was that the gcc people want -pthread to be the standard
>> way of sucking in thread support via their compiler. They intend the
>> -pthread option to be used across all operating systems, notably
>> including Linux.
>
> I see. How do we address the issue of having multiple threads
> libraries to
> choose from then? I take it using the libmap feature is not the answer.
First, I'm fully in favor of using "-pthread" to tell the compiler
"compile and link the code using whatever additional flags and
mechanisms are necessary to support POSIX threads", rather than having
to specific some combination of "-D_THREAD_SAFE -DPIC -lpthread", etc,
particularly as that combination changes from OS to OS, or even from
release to release within a specific OS.
Second, LD_PRELOAD is intended to solve the issue of "how do I
substitute a different version of a shared library (so long as it
provides the symbols needed by the program so that the executable
dynamicly links) than the one the program was actually linked against".
Solaris uses this mechanism to support different flavors of malloc
besides the default SCD-compliant one, such as bsdmalloc and mapmalloc,
and it also uses this mechanism to provide backwards compatibility with
buggy programs as per "man ld.so.1":
NOTES
The user compatibility library /usr/lib/0@0.so.1 provides a
mechanism that establishes a value of 0 at location 0. Some
applications exist that erroneously assume a null character
pointer should be treated the same as a pointer to a null
string. A segmentation violation will occur in these appli-
cations when a null character pointer is accessed. If this
library is added to such an application at runtime using
LD_PRELOAD, it provides an environment that is sympathetic
to this errant behavior. However, the user compatibility
library is intended neither to enable the generation of such
applications, nor to endorse this particular programming
practice.
For this to actually be useful (usable?) under FreeBSD, the implication
is that the different thread libraries which exist under FreeBSD need
to be interchangable via dynamic linking, rather than requiring
compile-time changes to the code using threads. I don't know whether
libpthreads, libc_r, and libkse can be switched using dynamic linking,
but if they can't, pick the best implementation and make it the default
that "cc -pthreads" uses.
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33E67F1E-B976-11D8-8148-003065ABFD92>