I forgot to include the following statistic:
repojail% grep duplicate_symbol regresslogs.out.wanted | wc -l
613
mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any
The latest build of amd64-CURRENT ports has just completed:
http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default=p546132_s364744
The number of build failures is now 740. This is an slight drop from
the initial post-clang11 commit of 830. This is due to diligent work
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
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,
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
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
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
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,
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.
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
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
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.
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
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
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
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.
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
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.
[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
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
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
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
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
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
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
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
* 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
* 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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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.
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
[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: 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
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
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
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
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,
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
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,
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
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, 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
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.
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
#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
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
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:
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
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,
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
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
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
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,
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
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, 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,
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.
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
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
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
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$
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
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
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
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
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
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
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
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
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
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
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
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
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
--
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
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
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
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
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
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
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
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
1 - 100 of 130 matches
Mail list logo
