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

2003-09-26 Thread Garrett Wollman
On Thu, 25 Sep 2003 19:33:06 -0700, David Schwartz [EMAIL PROTECTED] said: think '-pthread' is a good thing. It's nice to have a portable way to say that I want to compile POSIX code. What good is a standard if there's no standard way to get to it? The Standard way to do it is: c99

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

2003-09-25 Thread David Schwartz
David Xu wrote: I definitly agree with Dan, -pthread is too ugly, it really really is nothing to do with compiler and should be removed. Really? What if invoking the threading library required the compiler to compile code differently? Surely it might require that on some platforms,

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

2003-09-25 Thread David Xu
David Schwartz wrote: David Xu wrote: I definitly agree with Dan, -pthread is too ugly, it really really is nothing to do with compiler and should be removed. Really? What if invoking the threading library required the compiler to compile code differently? Surely it might require that

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

2003-09-24 Thread Scott Long
Daniel Eischen wrote: On Tue, 23 Sep 2003, David Schwartz wrote: On Mon, 22 Sep 2003, David Schwartz wrote: No. There are other environments that don't have -pthread though. So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently

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

2003-09-24 Thread Marcin Dalecki
Daniel Eischen wrote: 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. Yeah it would break. It would break in a way where the first thing I would suppose to be the case

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

2003-09-24 Thread Sheldon Hearn
On (2003/09/23 19:35), 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. Okay,

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

2003-09-24 Thread John Birrell
On Wed, Sep 24, 2003 at 11:51:53AM +0200, Sheldon Hearn wrote: Okay, so what are we supposed to do to ports that are now broken because -pthread doesn't exist (e.g. devel/pwlib)? -pthread is back in current. It just had a little holiday. It's back, refreshed, eager and willing to do the deed.

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

2003-09-24 Thread Alex Keahan
Why don't we make -pthread link to the *default* thread library (kse)? Solaris has a similar -mt option: -mt Passes D_REENTRANT to preprocessor. Appends -lthread after all other user-specified libraries on the command line. If you are doing your own multithread coding, you must

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

2003-09-24 Thread Sheldon Hearn
On (2003/09/24 20:18), John Birrell wrote: Okay, so what are we supposed to do to ports that are now broken because -pthread doesn't exist (e.g. devel/pwlib)? -pthread is back in current. It just had a little holiday. It's back, refreshed, eager and willing to do the deed. 8-) That's

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

2003-09-24 Thread Brad Knowles
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.

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

2003-09-24 Thread John Baldwin
On 23-Sep-2003 Dan Naumov wrote: On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I am one of those folks as well. As an

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

2003-09-24 Thread Robert Watson
On Wed, 24 Sep 2003, Scott Long wrote: I'm a big advocate of using libmap to deal with this. Ditto. Based on the results seen thus far, my preference would really be for: (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle. (2) Ship all packages and binaries using threading

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

2003-09-24 Thread freebsd-current
On Wed, 24 Sep 2003, Scott Long wrote: I'm a big advocate of using libmap to deal with this. Ditto. Based on the results seen thus far, my preference would really be for: (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle. (2) Ship all packages and binaries using

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

2003-09-24 Thread John Baldwin
On 23-Sep-2003 Scott Long wrote: Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library. This is trivial to fix.

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

2003-09-24 Thread Daniel Eischen
On Wed, 24 Sep 2003, Scott Long wrote: Daniel Eischen wrote: I'm running out of energy here. None of the threads guys want -pthread and if forced on them would prefer it to be a NOOP. I am trying very hard not to be biased towards one threads library over another, and having -pthread

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

2003-09-24 Thread Daniel Eischen
On Wed, 24 Sep 2003, John Baldwin wrote: On 23-Sep-2003 Dan Naumov wrote: On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to.

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

2003-09-24 Thread Jacques A. Vidrine
[Mostly trying to stay out of this thread, but I must comment at least on this point.] On Wed, Sep 24, 2003 at 11:01:01AM -0400, Daniel Eischen wrote: On Wed, 24 Sep 2003, Scott Long wrote: Daniel Eischen wrote: o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that are

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

2003-09-24 Thread Jacques A. Vidrine
On Wed, Sep 24, 2003 at 10:27:29AM -0500, Jacques A. Vidrine wrote: At link time, either (a) I want *this* threaded library damnit, or (b) ^^^ that one threading library might provide but not another. As an aside, apparently I

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

2003-09-24 Thread Ian Dowse
In message [EMAIL PROTECTED], Daniel Eischen writes: On Wed, 24 Sep 2003, Scott Long wrote: PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't mean anything outside of that. That just meant it makes it easier to maintain ports so that they are PTHREAD_LIBS compliant (they

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

2003-09-24 Thread Daniel Eischen
On Wed, 24 Sep 2003, Ian Dowse wrote: In message [EMAIL PROTECTED], Daniel Eischen writes: On Wed, 24 Sep 2003, Scott Long wrote: PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't mean anything outside of that. That just meant it makes it easier to maintain ports

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

2003-09-24 Thread John Baldwin
On 24-Sep-2003 Daniel Eischen wrote: On Wed, 24 Sep 2003, John Baldwin wrote: On 23-Sep-2003 Dan Naumov wrote: On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make

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

2003-09-24 Thread Garrett Wollman
I think it was John Baldwin who wrote: I think having a magic option to gcc that translates to 'link with the foo library' is rediculous. What's next, a gcc -math to get the math functions in libm? As far as POSIX is concerned, that's precisely how it works. `c99 foo.c -l m' means `link in

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

2003-09-24 Thread Dan Nelson
In the last episode (Sep 24), Daniel Eischen said: On Wed, 24 Sep 2003, Scott Long wrote: Daniel Eischen wrote: o Doesn't break applications that use both -pthread and -lthreadlib. We've been able to link both libc_r and libc in -current for well over 2 years. Indeed, if you

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

2003-09-24 Thread Robert Watson
On Wed, 24 Sep 2003, Dan Nelson wrote: Does it really matter if you end up linked to multiple threads libraries? The first library providing a symbol wins, so the other shlibs just won't get used at all. Libraries linked from the executable trump libraries linked from libraries, and

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

2003-09-24 Thread Michael Edenfield
* Ian Dowse [EMAIL PROTECTED] [030924 12:03]: In message [EMAIL PROTECTED], Daniel Eischen writes: On Wed, 24 Sep 2003, Scott Long wrote: PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't mean anything outside of that. That just meant it makes it easier to maintain

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

2003-09-24 Thread Michael Edenfield
* Michael Edenfield [EMAIL PROTECTED] [030924 13:21]: * Ian Dowse [EMAIL PROTECTED] [030924 12:03]: In message [EMAIL PROTECTED], Daniel Eischen writes: On Wed, 24 Sep 2003, Scott Long wrote: PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't mean anything outside

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

2003-09-24 Thread Andre Guibert de Bruet
On Wed, 24 Sep 2003, Garrett Wollman wrote: I think it was John Baldwin who wrote: I think having a magic option to gcc that translates to 'link with the foo library' is rediculous. What's next, a gcc -math to get the math functions in libm? As far as POSIX is concerned, that's

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

2003-09-24 Thread Daniel Eischen
On Wed, 24 Sep 2003, Dan Nelson wrote: In the last episode (Sep 24), Daniel Eischen said: On Wed, 24 Sep 2003, Scott Long wrote: Daniel Eischen wrote: o Doesn't break applications that use both -pthread and -lthreadlib. We've been able to link both libc_r and libc in

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

2003-09-24 Thread Andrea Campi
On Wed, Sep 24, 2003 at 05:03:28PM +0100, Ian Dowse wrote: Just to throw one further approach out on the table, below is a patch that makes gcc read from a file to determine what library to associate with the -pthread flag. It's a hack of course, and probably neither correct or optimal. If you

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

2003-09-24 Thread Matthew N. Dodd
On Wed, 24 Sep 2003, Daniel Eischen wrote: It isn't clear that libmap can deal with libraries that are linked to one specific threads library, and how libmap'd applications work. If mplayer is libmap'd to libthr, ogle is libmap'd to libpthread, and both are linked to libGL which is linked to

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

2003-09-24 Thread Daniel Eischen
On Wed, 24 Sep 2003, Matthew N. Dodd wrote: On Wed, 24 Sep 2003, Daniel Eischen wrote: It isn't clear that libmap can deal with libraries that are linked to one specific threads library, and how libmap'd applications work. If mplayer is libmap'd to libthr, ogle is libmap'd to

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

2003-09-24 Thread Garrett Wollman
On Wed, 24 Sep 2003 15:19:43 -0400 (EDT), Daniel Eischen [EMAIL PROTECTED] said: Eek, no. Libpthread is libpthread, libthr is libthr, etc. A symlink doesn't help you anyways because the library/application becomes dependent on the thing it is symlink'd to, not the symlink. That depends on

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

2003-09-24 Thread Daniel Eischen
On Wed, 24 Sep 2003, Michael Edenfield wrote: * Ian Dowse [EMAIL PROTECTED] [030924 12:03]: In message [EMAIL PROTECTED], Daniel Eischen writes: On Wed, 24 Sep 2003, Scott Long wrote: PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't mean anything outside of

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

2003-09-24 Thread Daniel Eischen
On Wed, 24 Sep 2003, Daniel Eischen wrote: On Wed, 24 Sep 2003, Michael Edenfield wrote: * Ian Dowse [EMAIL PROTECTED] [030924 12:03]: In message [EMAIL PROTECTED], Daniel Eischen writes: On Wed, 24 Sep 2003, Scott Long wrote: PTHREAD_LIBS is a great tool for the /usr/ports

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

2003-09-24 Thread Peter Wemm
Robert Watson wrote: Based on the results seen thus far, my preference would really be for: (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle. Regarding the switch, the gcc folks have been adding -pthread as the 'standard' way to enable pthreads across the board for all

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

2003-09-24 Thread David Xu
On Wednesday 24 September 2003 23:11, Daniel Eischen wrote: On Wed, 24 Sep 2003, John Baldwin wrote: On 23-Sep-2003 Dan Naumov wrote: On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and

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

2003-09-24 Thread Loren James Rittle
I was looking through gcc last night to see how conceptually difficult it would be to do something like this. But instead of a file, I was thinking of this process: * if env(PTHREADS_LIBS) then LDFLAGS += PTHREADS_LIBS * elseif fileexists(libpthread) then LDFLAGS += -lpthread * elseif

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

2003-09-24 Thread Daniel Eischen
On Wed, 24 Sep 2003, Loren James Rittle wrote: I was looking through gcc last night to see how conceptually difficult it would be to do something like this. But instead of a file, I was thinking of this process: * if env(PTHREADS_LIBS) then LDFLAGS += PTHREADS_LIBS * elseif

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

2003-09-23 Thread Daniel Eischen
On Mon, 22 Sep 2003, Scott Long wrote: Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library. This is trivial

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

2003-09-23 Thread Loren James Rittle
I'm all for removing it, but our FSF GCC maintainer thought it better to make it a NOOP. We're just going by his advice. I agreed that making -pthread == NOOP was probably better than the ~Sept 5 -CURRENT system compiler however that was not my full advice. In my view (and thus my advice), it

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

2003-09-23 Thread Daniel Eischen
On Tue, 23 Sep 2003, Loren James Rittle wrote: I'm all for removing it, but our FSF GCC maintainer thought it better to make it a NOOP. We're just going by his advice. I agreed that making -pthread == NOOP was probably better than the ~Sept 5 -CURRENT system compiler however that was not

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

2003-09-23 Thread David Schwartz
On Mon, 22 Sep 2003, David Schwartz wrote: No. There are other environments that don't have -pthread though. So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently from every other platform. On every other platform I know of

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

2003-09-23 Thread Daniel Eischen
On Tue, 23 Sep 2003, David Schwartz wrote: On Mon, 22 Sep 2003, David Schwartz wrote: No. There are other environments that don't have -pthread though. So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently from every

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

2003-09-23 Thread Dan Naumov
On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I am one of those folks as well. As an end-user, I am not interested in hacking around the source of 3rd-party applications that use

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

2003-09-23 Thread Dan Naumov
On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I am one of those folks as well. As an end-user, I am not interested in hacking

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

2003-09-23 Thread Marcin Dalecki
Scott Long wrote: I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. You have to decide what the therading lib should be indeed.

Re: [JunkMail] RE: Fixing -pthreads (Re: ports and -current)

2003-09-23 Thread Mark Woodson
On Tuesday 23 September 2003 01:25 pm, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I am one of those folks as well. As an end-user, I am not interested in

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

2003-09-23 Thread Andrea Campi
[cc trimmed] Hi Daniel, On Tue, Sep 23, 2003 at 04:13:11PM -0400, Daniel Eischen wrote: However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation. You can't make it variable.

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

2003-09-23 Thread mike
(Re: ports and -current) ... From a practical point of view: In former times nobody complained when we had only one threading library: libc_r. The only complaints came from its shortcomings... So could we please define that: - libpthread (aka libkse) is the primary threading library under FreeBSD

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

2003-09-23 Thread Daniel Eischen
On Tue, 23 Sep 2003, Marcin Dalecki wrote: Scott Long wrote: I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. You

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

2003-09-23 Thread Daniel Eischen
On Tue, 23 Sep 2003, Andrea Campi wrote: [cc trimmed] Hi Daniel, On Tue, Sep 23, 2003 at 04:13:11PM -0400, Daniel Eischen wrote: However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for

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

2003-09-23 Thread Marcin Dalecki
Daniel Eischen wrote: On Tue, 23 Sep 2003, Marcin Dalecki wrote: Scott Long wrote: I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread

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

2003-09-23 Thread Daniel Eischen
On Wed, 24 Sep 2003, Marcin Dalecki wrote: Daniel Eischen wrote: On Tue, 23 Sep 2003, Marcin Dalecki wrote: Scott Long wrote: I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But,

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

2003-09-22 Thread Daniel Eischen
On Sun, 21 Sep 2003, Scott Long wrote: Doug Barton wrote: E... I'm not sure this is an optimal solution. There is an awful lot of software out there which expects -pthread to just work. Wouldn't it make more sense to default it to one thing or the other, then make it configurable

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

2003-09-22 Thread David Schwartz
On Sun, 21 Sep 2003, Scott Long wrote: Most everyone that writes threaded applications and runs on multiple platforms knows that most thread libraries are called libpthread and are linked to with -lpthread. Once we rename libkse to libpthread, the problem largely goes away. The porter,

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

2003-09-22 Thread Daniel Eischen
On Mon, 22 Sep 2003, David Schwartz wrote: There will be a libpthread and -pthread will be NOOP'd. It should be a very familiar environment. You know another environment that has '-pthread' (that is, it does not produce an error) but fails to compile and link pthreads code when that

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

2003-09-22 Thread Scott Long
Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library. This is trivial to fix. It's not like we're making someone change

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

2003-09-22 Thread Will Andrews
On Mon, Sep 22, 2003 at 10:35:10PM -0600, Scott Long wrote: [...] Scott said it all for me. Seriously. The whole idea of breaking backwards de-facto compatibility is bad, bad, bad. Regards, -- wca ___ [EMAIL PROTECTED] mailing list

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

2003-09-22 Thread Steve Kargl
On Mon, Sep 22, 2003 at 10:35:10PM -0600, Scott Long wrote: Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library.

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

2003-09-22 Thread Scott Long
Steve Kargl wrote: On Mon, Sep 22, 2003 at 10:35:10PM -0600, Scott Long wrote: Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the

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

2003-09-21 Thread Will Andrews
#55325. I suggest that people not build ports on -CURRENT for a few weeks until things get sorted out, unless they're going to fix the problems with specific ports. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo

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

2003-09-21 Thread Daniel Eischen
On Sat, 20 Sep 2003, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: What, precisely, do you object to in the above proposal? 1, 2, and 3. I don't think backing out -pthread change helps much in fixing ports... Again, why? Please explain

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

2003-09-21 Thread Will Andrews
On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: Because when things break, people fix them. There is no motivation (as seen in the last 2+ years) to fix something that isn't broken. Please also see:

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

2003-09-21 Thread Kris Kennaway
On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: On Sat, 20 Sep 2003, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: What, precisely, do you object to in the above proposal? 1, 2, and 3. I don't think backing out -pthread change

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

2003-09-21 Thread Daniel Eischen
On Sat, 20 Sep 2003, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: On Sat, 20 Sep 2003, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: What, precisely, do you object to in the above proposal? 1, 2,

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

2003-09-21 Thread Will Andrews
On Sun, Sep 21, 2003 at 03:17:28AM -0400, Daniel Eischen wrote: From what I've recently read, the freeze should be lifting this week. Can we hold off till then? Is a few more days going to matter? If the freeze continues longer than expected, I'll back the change out until it's over. I

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

2003-09-21 Thread Mark Linimon
IMHO if the ports tree is unfrozen for the -pthreads fixes, the 4.9 release schedule will drift days if not weeks. While it's not as apparent as the kernel build issues, there are significant QA issues that go into the ports system. That's why the freeze is in place, to allow the QA process to

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

2003-09-21 Thread Mark Linimon
I don't think committing fixes for -current breakages should cause problems for 4.9-RELEASE (especially with the caveat that they be compile tested on -stable). It takes several days to do the compile QA. That's assuming that no actual users are allowed to have time to test the changes before

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

2003-09-21 Thread Daniel Eischen
On Sun, 21 Sep 2003, Will Andrews wrote: On Sun, Sep 21, 2003 at 03:17:28AM -0400, Daniel Eischen wrote: From what I've recently read, the freeze should be lifting this week. Can we hold off till then? Is a few more days going to matter? If the freeze continues longer than expected,

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

2003-09-21 Thread Doug Barton
On Sun, 21 Sep 2003, Daniel Eischen wrote: Well, actually it is directly related. Part of the plan to transition to libpthread is making ports PTHREAD_LIBS compliant. As stated in that thread, if a libpthread exists on the system, autoconf/configure will pick it up and the port will also end

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

2003-09-21 Thread John Birrell
On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? They need to replace -pthread with their thread library of choice (e.g. -lc_r or

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

2003-09-21 Thread Daniel Eischen
On Sun, 21 Sep 2003, Doug Barton wrote: On Sun, 21 Sep 2003, Daniel Eischen wrote: Well, actually it is directly related. Part of the plan to transition to libpthread is making ports PTHREAD_LIBS compliant. As stated in that thread, if a libpthread exists on the system,

Re: ports and -current

2003-09-21 Thread Tim Kientzle
John Birrell wrote: On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: At the very least, we should put [-pthread] back as a noop. The timing on this really sucks because it breaks the ports tree for an extended period of time. While the fixes are simple, they haven't been made yet.

Re: ports and -current

2003-09-21 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Tim Kientzle [EMAIL PROTECTED] writes: : John Birrell wrote: : On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: : At the very least, we should put [-pthread] back as a noop. The timing on : this really sucks because it breaks the ports

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

2003-09-21 Thread Doug Barton
On Sun, 21 Sep 2003, John Birrell wrote: On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? They need to replace -pthread with

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

2003-09-21 Thread Daniel Eischen
On Sun, 21 Sep 2003, Doug Barton wrote: On Sun, 21 Sep 2003, John Birrell wrote: On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the

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

2003-09-21 Thread Dan Naumov
On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: We've already been over this before. The problem is not as bad as you think, and there are other platforms that don't have -pthread. And those platforms would be? Sincerely, Dan Naumov ___ [EMAIL

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

2003-09-21 Thread Daniel Eischen
On Mon, 22 Sep 2003, Dan Naumov wrote: On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: We've already been over this before. The problem is not as bad as you think, and there are other platforms that don't have -pthread. And those platforms would be? Solaris for one: bash-2.05$

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

2003-09-21 Thread Daniel Eischen
On Sun, 21 Sep 2003, Daniel Eischen wrote: On Mon, 22 Sep 2003, Dan Naumov wrote: On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: We've already been over this before. The problem is not as bad as you think, and there are other platforms that don't have -pthread. And those

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

2003-09-21 Thread Scott Long
Doug Barton wrote: On Sun, 21 Sep 2003, John Birrell wrote: On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? They need to replace

ports and -current

2003-09-20 Thread Harald Schmalzbauer
on -current? I'm asking because my workstation has enough resources to track -current to help testing. But if I breake ports with -current I won't keep tracking it. Thanks, -Harry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman

Re: ports and -current

2003-09-20 Thread Kris Kennaway
aren't) also the entire new kde fails. Is there no aim to have ports running on -current? Also incorrect. The 4.9 ports freeze is holding up commits to fix compile failures on 5.1. Kris pgp0.pgp Description: PGP signature

Re: ports and -current

2003-09-20 Thread Jeremy Messenger
others aren't) also the entire new kde fails. Is there no aim to have ports running on -current? Check in the bottom at http://lists.freebsd.org/pipermail/freebsd-gnome/2003-September/002846.html .. I believe, we should be expect to see the many fixes for -CURRENT when the ports freeze lift. Cheers

Re: ports and -current

2003-09-20 Thread Harald Schmalzbauer
are easy to fix others aren't) also the entire new kde fails. Is there no aim to have ports running on -current? Also incorrect. The 4.9 ports freeze is holding up commits to fix compile failures on 5.1. Oh I see. Thats a reason. If I only knew about that freeze before my pkg_delete

Re: ports and -current

2003-09-20 Thread Matt
Harald Schmalzbauer wrote: Oh I see. Thats a reason. If I only knew about that freeze before my pkg_delete -a but that's just my problem Thanks, -Harry I unfortunatly did the same thing. I wanted to upgrade to gnome 2.4 and seeing as this box really doesn't have any ports installed other

Re: ports and -current

2003-09-20 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Harald Schmalzbauer [EMAIL PROTECTED] writes: : Not only the -pthread removement broke countless ports (some of them are Maybe I missed the reason why FreeBSD needs to be unique wrt threading programs and not have -pthread... Warner

Re: ports and -current

2003-09-20 Thread Daniel Eischen
On Sat, 20 Sep 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Harald Schmalzbauer [EMAIL PROTECTED] writes: : Not only the -pthread removement broke countless ports (some of them are Maybe I missed the reason why FreeBSD needs to be unique wrt threading programs and

Re: ports and -current

2003-09-20 Thread Doug Barton
On Sat, 20 Sep 2003, Daniel Eischen wrote: On Sat, 20 Sep 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Harald Schmalzbauer [EMAIL PROTECTED] writes: : Not only the -pthread removement broke countless ports (some of them are Maybe I missed the reason why

Re: ports and -current

2003-09-20 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : On Sat, 20 Sep 2003, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Harald Schmalzbauer [EMAIL PROTECTED] writes: : : Not only the -pthread removement broke countless ports (some of them

Re: ports and -current

2003-09-20 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Doug Barton [EMAIL PROTECTED] writes: : I'd really like to see this change backed out, at minimum until the : ports freeze is over. Me too. I'd like to see a discussion of this in arch@ as well. I know that people have a low bikeshed tolerance these

Re: ports and -current

2003-09-20 Thread Dan Naumov
On Sun, 2003-09-21 at 04:09, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Doug Barton [EMAIL PROTECTED] writes: : I'd really like to see this change backed out, at minimum until the : ports freeze is over. My thoughts exactly. Sincerely, Dan Naumov --

Re: ports and -current

2003-09-20 Thread John Birrell
On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote: Why does -pthread necessarily force selection of one specific threading library? All it means is that it is that the program uses posix threads, at least traditionally. How FreeBSD causes that to happen is an interesting

Re: ports and -current

2003-09-20 Thread M. Warner Losh
In message: [EMAIL PROTECTED] John Birrell [EMAIL PROTECTED] writes: : On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote: : Why does -pthread necessarily force selection of one specific : threading library? All it means is that it is that the program uses : posix

Re: ports and -current

2003-09-20 Thread John Birrell
On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: But it was completely removed. That sounds like the consensus wasn't followed. Why was it then removed? It got discussed a bit more after the removal. That was the time when the GCC people got involved. The discussions where on

Fixing -pthreads (Re: ports and -current)

2003-09-20 Thread Kris Kennaway
On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote: On Sat, 20 Sep 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Harald Schmalzbauer [EMAIL PROTECTED] writes: : Not only the -pthread removement broke countless ports (some of them are Maybe I

Re: ports and -current

2003-09-20 Thread M. Warner Losh
In message: [EMAIL PROTECTED] John Birrell [EMAIL PROTECTED] writes: : On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: : But it was completely removed. That sounds like the consensus wasn't : followed. Why was it then removed? : : It got discussed a bit more after

Re: ports and -current (really 4.9 stability)

2003-09-20 Thread Frank Mayhar
M. Warner Losh wrote: FWIW, I'm running today's RELENG_4 w/o PAE. I'll see if there are big issues. FYI, I've been running 4.9-prerelease since last week, all without PAE. Booted it on all my boxen (including a web server and a database server) as well as doing hardware reconfigurations and

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

2003-09-20 Thread John Birrell
On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: 3) You, John Birrell, and whoever else is interested in fixing these ports can work on them at your own pace without disrupting life for the rest of the users. Once they're all fixed, we can turn the error back on or make it a NOP

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

2003-09-20 Thread Kris Kennaway
On Sun, Sep 21, 2003 at 02:03:40PM +1000, John Birrell wrote: On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: 3) You, John Birrell, and whoever else is interested in fixing these ports can work on them at your own pace without disrupting life for the rest of the users. Once

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

2003-09-20 Thread Joe Marcus Clarke
On Sun, 2003-09-21 at 00:22, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 02:03:40PM +1000, John Birrell wrote: On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: 3) You, John Birrell, and whoever else is interested in fixing these ports can work on them at your own pace

  1   2   >