Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, 24 Jan 2001, Maxim Sobolev wrote: It's not a very accurate estimate, as the magic can be in the distfile itself, i.e. properly written configure script or makefile may know that FreeBSD need a -pthread and -D_THREAD_SAFE. For some unknown reason, math.h needs _REENTRANT in FreeBSD to declare gamma_r, lgamma_r, gammaf_r and lgammaf_r. Perhaps this could be changed too. I don't know what the POSIX standard says about this. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
"Daniel M. Eischen" wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. Could you please bump version number of libc/libc_r shared libraries, so the programs linked with older version will still work correctly? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, Jan 24, 2001 at 03:37:24PM +0200, Maxim Sobolev wrote: "Daniel M. Eischen" wrote: For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. Could you please bump version number of libc/libc_r shared libraries, so the programs linked with older version will still work correctly? AFAIK, we don't bump library version numbers for -current. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, 24 Jan 2001, Maxim Sobolev wrote: "Daniel M. Eischen" wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. Could you please bump version number of libc/libc_r shared libraries, so the programs linked with older version will still work correctly? It's already been bumped in -current so that we _can_ do stuff like this. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
Daniel Eischen wrote: On Wed, 24 Jan 2001, Maxim Sobolev wrote: "Daniel M. Eischen" wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. Could you please bump version number of libc/libc_r shared libraries, so the programs linked with older version will still work correctly? It's already been bumped in -current so that we _can_ do stuff like this. Ah, ok. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
* Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. This is ambiguous, can you provide old/new examples of how to compile/link a single C source file? thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. This is ambiguous, can you provide old/new examples of how to compile/link a single C source file? 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 Obviously -Wall isn't necessary, but it should be mandatory :-) -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
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 H. 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. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
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 H. 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
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
In the last episode (Jan 24), Daniel Eischen said: On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. This is ambiguous, can you provide old/new examples of how to compile/link a single C source file? 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 I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply add -pthread. Only 7 also add -D_THREAD_SAFE. The only usage of _THREAD_SAFE in /usr/include is redefinition of feof, ferror, clearerr, and fileno to *_unlocked. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
* Dan Nelson [EMAIL PROTECTED] [010124 10:32] wrote: In the last episode (Jan 24), Daniel Eischen said: On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. This is ambiguous, can you provide old/new examples of how to compile/link a single C source file? 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 I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply add -pthread. Only 7 also add -D_THREAD_SAFE. The only usage of _THREAD_SAFE in /usr/include is redefinition of feof, ferror, clearerr, and fileno to *_unlocked. -D_THREAD_SAFE used to (or still does) make various foo_r function prototypes available. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
Dan Nelson wrote: In the last episode (Jan 24), Daniel Eischen said: On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. This is ambiguous, can you provide old/new examples of how to compile/link a single C source file? 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 I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply add -pthread. Only 7 also add -D_THREAD_SAFE. It's not a very accurate estimate, as the magic can be in the distfile itself, i.e. properly written configure script or makefile may know that FreeBSD need a -pthread and -D_THREAD_SAFE. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, 24 Jan 2001, Dan Nelson wrote: In the last episode (Jan 24), Daniel Eischen said: On Wed, 24 Jan 2001, Alfred Perlstein wrote: * Daniel M. Eischen [EMAIL PROTECTED] [010124 05:26] wrote: As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. This is ambiguous, can you provide old/new examples of how to compile/link a single C source file? 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 I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply add -pthread. Only 7 also add -D_THREAD_SAFE. The only usage of _THREAD_SAFE in /usr/include is redefinition of feof, ferror, clearerr, and fileno to *_unlocked. That's if _THREAD_SAFE isn't defined, otherwise the MT-safe versions of those functions are used. The same for getc(), putc(), getchar(), putchar(). If the application isn't using those functions, nor calling anything in libc that uses them, then there shouldn't be a problem in not defining _THREAD_SAFE. But to be correct, and if you see gcc(1), -D_THREAD_SAFE is recommended. This is not the case in -current; -D_THREAD_SAFE is not needed (but will not be harmful if it is used). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
In the last episode (Jan 24), Maxim Sobolev said: Dan Nelson wrote: I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply add -pthread. Only 7 also add -D_THREAD_SAFE. It's not a very accurate estimate, as the magic can be in the distfile itself, i.e. properly written configure script or makefile may know that FreeBSD need a -pthread and -D_THREAD_SAFE. Right; I only scanned for ports that had been patched to support our pthreads. I checked a couple of other ports that I know have native threads support (gnut, db3, mysql) and only db3 adds -D_THREAD_SAFE. The pthread(3) manpage doesn't mention -D_THREAD_SAFE at all. Would it be a good idea to edit the specs file in -STABLE to add that define when the user compiles with -pthread? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
Dan Nelson wrote: In the last episode (Jan 24), Maxim Sobolev said: Dan Nelson wrote: I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply add -pthread. Only 7 also add -D_THREAD_SAFE. It's not a very accurate estimate, as the magic can be in the distfile itself, i.e. properly written configure script or makefile may know that FreeBSD need a -pthread and -D_THREAD_SAFE. Right; I only scanned for ports that had been patched to support our pthreads. I checked a couple of other ports that I know have native threads support (gnut, db3, mysql) and only db3 adds -D_THREAD_SAFE. The pthread(3) manpage doesn't mention -D_THREAD_SAFE at all. Would it be a good idea to edit the specs file in -STABLE to add that define when the user compiles with -pthread? No, I think it would violate POLA. AFAIK, the most that you can to do is to mention it somehow in pthread manpage. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
In message [EMAIL PROTECTED] Alfred Perlstein writes: : -D_THREAD_SAFE used to (or still does) make various foo_r function : prototypes available. Currently it does not do this. The foo_r prototypes are always available. Well, when we aren't compiling _ANSI_SOURCE or _POSIX_SOURCE. Dan was right that the only places that _THREAD_SAFE was used was in stdio.h for the unlocked versions of stdio routines. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, Jan 24, 2001 at 07:07:20PM -0400, Craig Hawco wrote: On Wed, 24 Jan 2001, Daniel Eischen wrote: 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). Why not just call it libpthread for the sake of consistancy with other OSes? I understand why it was called libc_r, but it no longer contains the libc functionality. I know we like being nonconformist, but sometimes consistancy is a Good Thing. Because libpthread will be written as part of the KSE project, and this way we have two different names for the different libraries, as opposed to "the new libpthread" and "the old libpthread". -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, 24 Jan 2001, Garrett Rooney wrote: On Wed, Jan 24, 2001 at 07:07:20PM -0400, Craig Hawco wrote: On Wed, 24 Jan 2001, Daniel Eischen wrote: 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). Why not just call it libpthread for the sake of consistancy with other OSes? I understand why it was called libc_r, but it no longer contains the libc functionality. I know we like being nonconformist, but sometimes consistancy is a Good Thing. Because libpthread will be written as part of the KSE project, and this way we have two different names for the different libraries, as opposed to "the new libpthread" and "the old libpthread". I see, very well then. =) Happy coding. --Craig -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-ports" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
