< 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 foo.c -l pthread
-GAWollman
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 on
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,
s
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 f
>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
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 th
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 pl
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
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 anyt
< 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 what the SONAME entry says It is technically
feasible to have lib
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 li
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 linke
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
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
> > > > -l. We've been able to link both libc_r and libc
> > > >
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, t
* 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
> > >>
* 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 ea
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 LD_
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
> > > -l. We've been able to link both libc_r and libc
> > > in -current for well over 2 years. Indeed, if y
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 `lin
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 "
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 m
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 complian
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
[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
> > >
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
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 -p
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
>
> 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
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 w
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.
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.
I
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
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 u
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.
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.
Ok
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 would
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 from
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 th
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
sa
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 def
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
<[EMAIL PROTECTED]>
> Subject: RE: Fixing -pthreads (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:
-
[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 va
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
> inter
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.
Ho
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
>
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 us
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 f
> 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 o
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 w
> 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), i
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
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 thr
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 li
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
http://lists.fre
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
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 whe
> 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 port
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 confi
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 -pthr
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.
> >
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
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
___
[EMAI
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
> > >
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
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,
> > autoc
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 -
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
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 expecte
> 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
befo
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 ru
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
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?
>
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 -p
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:
>
>
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/
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 exp
On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote:
> OK, here's what we can do to fix this:
>
> 1) Put back -pthread in -current so all the ports don't fail
>
> 2) I will build a full set of -current packages with the -pthread
> error still in place, to determine the list of packages
On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote:
> 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). Out of curiosity, what's the reason
> the tag can't be laid now?
On Sat, 20 Sep 2003, Kris Kennaway wrote:
> On Sun, Sep 21, 2003 at 01:04:49AM -0400, Daniel Eischen wrote:
> > On Sat, 20 Sep 2003, Kris Kennaway wrote:
> >
> > > On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote:
> > > > On Sat, 20 Sep 2003, M. Warner Losh wrote:
> > > >
> > > > >
On Sun, Sep 21, 2003 at 01:04:49AM -0400, Daniel Eischen wrote:
> On Sat, 20 Sep 2003, Kris Kennaway wrote:
>
> > 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]>
> > > > Hara
On Sat, 20 Sep 2003, 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 with
On Sat, 20 Sep 2003, Kris Kennaway wrote:
> 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 remo
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 pa
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.
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
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
> >
>
87 matches
Mail list logo
