On Wed, 24 Jan 2001, Jordan Hubbard wrote:
> > What's not clear ;-) Use -lc_r instead of -pthread.
> >
> > gcc -Wall -o foo foo.c -lc_r
> >
> > The old way was:
> >
> > gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread
>
> Hmmmm. And does the -pthread argument do anything anymore? If not,
> why not have it default to simply linking in libc_r for POLA's sake
> and ease of transition? If it does do something different now,
> perhaps you could explain what that is for all of us who are also
> confused. :)
OK, from the original email I sent to -arch and -current in
the "Request For Review:...":
For those not familiar with our current libc_r, it is currently
built to include a thread-safe libc as well as the POSIX threads
routines. On the other hand, libc is built to be non-thread
safe. This differs from other OSs and from what POSIX mandates
and means that we require non-standard hacks like the linker
option -pthread (which links to libc_r and prevents linking to
libc).
Using -pthread will prevent linking to libc and only link to
libc_r. After the change I just committed, you need to link
to both libc_r and libc (in that order), just like you would
for a threaded application on just about any other OS (only
ours is called libc_r instead of libpthread).
John Polstra has a simple patch that will change the semantics
of -pthread. This is obriens territory and I've steered clear
of touching anything in there. I sent him an email a few days
ago about this, but he's away for a couple of weeks and won't
be able to do anything about it until he gets back. I'll
test Johns patch, which should work just fine, and we'll let
_him_ commit it ;-)
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
