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

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

Reply via email to