subject:"Fixing \-pthreads \(Re\: ports and \-current\)"

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 automatically link to libpthread gives preference to
  it over libthr (or libthread (KSE in 1:1 mode) or libc_r).
  
  Pros:
o Allows us to define macros common to all the threads libraries.
o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that
  are not dependent on a particular threads library, but will use
  whatever threads library the application uses (i.e., you want mplayer
  to use libpthread and ogle to use libthr).
 
 I'm a big advocate of using libmap to deal with this.

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 libc_r, what happens?

At the least, -pthread should be a NOOP when building
shared and dynamic.

o If we support LD_PRELOAD properly, will allow us to select the
  threads library without having to rebuild/relink the application.
 
 I'm a big advocate of using libmap to deal with this.

libmap is in /etc and not writable by normal users.
LD_PRELOAD can be set in a script or command line.
Our FSF GCC maintainer has been advocating it and
it solves the problem without the need for libmap.

 
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 build KDE and X with libpthread installed,
  you will see binaries that are linked to both libc_r and libpthread.
 
 I can't see how this behaviour would not be considered a bug, if it is
 indeed true.  Are you saying that there are packages out there that will
 detect both -lpthread and -pthread and attempt to use both on the
 compilers and linker lines?

Yes, it's not just that.  They can also find libc_r and include
that (-lc_r) with -pthread.  I installed libkse as libpthread and
made the appropriate links and built X and KDE and there were
a lot of binaries that were linked to both libc_r and libpthread.
Perhaps this is because some shared libraries were linked to
one or the other while the applications got linked to the other
one -- I don't know.  Making -pthread a NOOP when building
shared libraries may help the situation.

o Makes it easier to spot ports that are not PTHREAD_LIBS compliant.
 
 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 would break when linked).
I know it has no bearing on 3rd party stuff.

 I suspect that the majority of users won't give a hoot about the
 mechanics of all of this as long as it Just Works.  The more 
 sophisticated users that want to mix/match threading libraries can be
 expected to exert a little more effort and learn the tools like libmap,
 etc.
 
  
  Cons:
o Third party applications that use -pthread exclusively (without
  linking to a threads library) will have to add a link option.
 
 This is where I have the biggest problem.  I firmly believe that it is
 incorrect for you to downplay this scenario, and it appears that others
 agree too.  This is the case that will give us the black eye with users
 and developers that want things to Just Work.

Well, we can agree to disagree :-)  I think folks are getting
upset that -pthread is an error and seeing all the problems
in ports and thinking the same thing is going to happen in
3rd party applications.  Things aren't nearly as broke when
it is a NOOP _and_ we have libpthread installed.  Any configure
script I've seen looks for -lpthread and will use it.

  I understand that folks want to wave their hands and say just make
  -pthread work and do whatever it needs to.  I'm like that myself.
  I just don't think it's a good idea.
  
 
 I'm unclear why it is impossible to do this.  The whole point of 
 -pthread is to make it Just Work.  We have complete control over how
 we make that happen.  Why is it impossible to make -pthread honor
 PTHREAD_LIBS?

PTHREAD_LIBS is an bsd.port.mk thing.  -pthread is a compiler
switch (contrib/gcc/config/freebsd-spec.h).  I certainly don't
know how you would do this.

  Why is it impossible to fix ports that try to
 mix pthread schemas?

It's not impossible, it's just not as easy to spot them because
they don't break when building.  You have to wade through complaints
saying X doesn't work correctly, what happened? and hopefully
get an 'ldd X' out of them so you can spot the problem.  Then
you have to figure out if it was the X port or something else
that it is linked to which has the problem.

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

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.
  
  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 -pthread
  when compiling them from source myself. Not in the slightest. This is
  BAD BAD BAD for usability.
  
  Sincerely,
  Dan Naumov
  
  I also believe that a question has to be asked, what do the -core and
  -arch people think of all this ? I think that they should have the final
  say in the matter.
 
 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?  The fact that functions live in libraries and that
 to get access to said functions you link with said libraries has been
 the practice on Un*x for longer than I've been alive.  Please, people,
 let the -pthread hack die and just use -lmumble thread library.
 I think any FreeBSD-specific -pthread bits should just be removed
 and have the compiler complain about a bogus option.  If gcc chooses
 to have a machine independent -pthread (or -thread) to turn on TLS or
 some such, that's great and all, but that would be gcc code, not
 FreeBSD-specific code.

Where were you a few days ago!

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 not dependent on a particular threads library, but will use
   whatever threads library the application uses (i.e., you want mplayer
   to use libpthread and ogle to use libthr).
  
  I'm a big advocate of using libmap to deal with this.
 
 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 libc_r, what happens?
 
 At the least, -pthread should be a NOOP when building
 shared and dynamic.

While libmap is a very neat hack and very useful, it is indeed
a hack and I do not think it should be the primary method of
determining what libraries to load.  The mere existance of a
libmap.conf file means additional file opening and parsing every time
a dynamically linked executable is loaded; as well as one or more
string searches/substitutions for every dynamic object name that rtld
encounters (not just thread libraries).

I believe that we should be able to make decisions at link time and at
run time.

At link time, either (a) I want *this* threaded library damnit, or (b)
choose a threaded library at run time, with (b) being the default.
Choosing (a) probably allows you to shoot your foot by mixing
threading libraries, but it may also allow you to use `extensions'
that one threading library might provide but not another.

At run time (if (b) was chosen at link time): use *this* threaded
library.  By what mechanism?  I imagined that there could be a library
(say libpthread :-P) that made the decision and loaded the *real*
threading library and forwarded or fixed-up thread-related functions.
A degenerate-but-simple implementation might be a symlink.

This seems to be more-or-less what GCC developer Loren James Rittle
[EMAIL PROTECTED] had in mind when he posted the
following suggestion to freebsd-threads some weeks back:

  Thank you for considering these words.  BTW, wouldn't it be cooler
  if (example only):
  
  -pthread (whatever the system default)
  -pthread=1 (1 process, aka -lc_r)
  -pthread=1:1 (1 process per thread, aka -lthr)
  -pthread=M:N (M threads in N processes, aka -lkse)
  -pthread=late/weak (perhaps not good ELF form, link against a stub to
  which all POSIX thread libraries on FreeBSD must conform, do not
  record the dependency ala FreeBSD4 default for -lc; or that does it in
  a weak manner en mass such that binding is deferred to the final
  selection made at a final link time)

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME  . FreeBSD UNIX   . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 couldn't (or at least didn't) decide
between `threaded library' and `threading library'.  I wasn't trying to
make some subtle distinction here :-)   Probably I should have said
`thread library' throughout.

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME  . FreeBSD UNIX   . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 would break when linked).
I know it has no bearing on 3rd party stuff.

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 want to make -pthread mean libkse,
create an /etc/pthread.libs that looks like:

-lc_r:  -lkse
-lc_r_p:-lkse_p

I haven't been following the discussion in any detail - this is
just another possibility that is worth mentioning as it could retain
compatibility for users that want -pthread to mean use the default
thread library.

Ian

Index: gcc.c
===
RCS file: /dump/FreeBSD-CVS/src/contrib/gcc/gcc.c,v
retrieving revision 1.36
diff -u -r1.36 gcc.c
--- gcc.c   11 Jul 2003 04:45:39 -  1.36
+++ gcc.c   24 Sep 2003 15:37:14 -
@@ -331,6 +331,7 @@
 
 static const char *if_exists_spec_function PARAMS ((int, const char **));
 static const char *if_exists_else_spec_function PARAMS ((int, const char **));
+static const char *thread_lib_override_spec_function PARAMS ((int, const char **));
 
 /* The Specs Language
 
@@ -1440,6 +1441,7 @@
 {
   { if-exists,   if_exists_spec_function },
   { if-exists-else,  if_exists_else_spec_function },
+  { thread-lib-override, thread_lib_override_spec_function },
   { 0, 0 }
 };
 
@@ -7335,4 +7337,46 @@
 return argv[0];
 
   return argv[1];
+}
+
+/* thread-lib-override built-in spec function.
+
+   Override a thread library according to /etc/pthread.libs  */
+
+static const char *
+thread_lib_override_spec_function (argc, argv)
+ int argc;
+ const char **argv;
+{
+  static char buf[256];
+  FILE *fp;
+  int n;
+  
+  /* Must have exactly one argument.  */
+  if (argc != 1)
+return NULL;
+
+  fp = fopen (/etc/pthread.libs, r);
+  if (fp == NULL)
+return argv[0];
+
+  while (fgets (buf, sizeof(buf), fp) != NULL)
+{
+  n = strlen (buf);
+  while (n  0  buf[n - 1] == '\n')
+   buf[--n] = '\0';
+  if (buf[0] == '#' || buf[0] == '\0')
+   continue;
+  n = strlen (argv[0]);
+  if (strncmp (buf, argv[0], n) != 0 || n = sizeof (buf) || buf[n] != ':')
+   continue;
+  n++;
+  while (buf[n] != '\0'  isspace ((unsigned char)buf[n]))
+   n++;
+  fclose (fp);
+
+  return buf[n];
+}
+  fclose (fp);
+  return argv[0];
 }
Index: config/freebsd-spec.h
===
RCS file: /dump/FreeBSD-CVS/src/contrib/gcc/config/freebsd-spec.h,v
retrieving revision 1.14
diff -u -r1.14 freebsd-spec.h
--- config/freebsd-spec.h   21 Sep 2003 07:59:16 -  1.14
+++ config/freebsd-spec.h   24 Sep 2003 15:38:11 -
@@ -160,8 +160,8 @@
 #if __FreeBSD_version = 500016
 #define FBSD_LIB_SPEC \
   %{!shared:   \
-%{!pg: %{pthread:-lc_r} -lc}   \
-%{pg:  %{pthread:-lc_r_p} -lc_p}   \
+%{!pg: %{pthread:%:thread-lib-override(-lc_r)} -lc}\
+%{pg:  %{pthread:%:thread-lib-override(-lc_r_p)} -lc_p}\
   }
 #else
 #define FBSD_LIB_SPEC \
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 so that
 they are PTHREAD_LIBS compliant (they would break when linked).
 I know it has no bearing on 3rd party stuff.
 
 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.

Hey, neat.  I wouldn't have known how to do such a thing from
gcc.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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
   -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 -pthread
  when compiling them from source myself. Not in the slightest. This is
  BAD BAD BAD for usability.
  
  Sincerely,
  Dan Naumov
  
  I also believe that a question has to be asked, what do the -core and
  -arch people think of all this ? I think that they should have the final
  say in the matter.
 
 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?  The fact that functions live in libraries and that
 to get access to said functions you link with said libraries has been
 the practice on Un*x for longer than I've been alive.  Please, people,
 let the -pthread hack die and just use -lmumble thread library.
 I think any FreeBSD-specific -pthread bits should just be removed
 and have the compiler complain about a bogus option.  If gcc chooses
 to have a machine independent -pthread (or -thread) to turn on TLS or
 some such, that's great and all, but that would be gcc code, not
 FreeBSD-specific code.
 
 Where were you a few days ago!

DNS problems == no outbound e-mail. :-P   If gcc does want to go with
a gcc-mandated -pthread option, then we should follow suit with that
(and it seems that gcc might), but I don't think we need a FreeBSD-only
flag if gcc doesn't mandate a -pthread option.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 the math functions, wherever they may
happen to live'.  Likewise `-l rt' for realtime -- and (relevant to
this discussion) `-l pthread' for threads.  There is no requirement
that any of these libraries exist as such.

-GAWollman

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 build KDE
   and X with libpthread installed, you will see binaries that
   are linked to both libc_r and libpthread.
  
  I can't see how this behaviour would not be considered a bug, if it
  is indeed true.  Are you saying that there are packages out there
  that will detect both -lpthread and -pthread and attempt to use
  both on the compilers and linker lines?
 
 Yes, it's not just that.  They can also find libc_r and include that
 (-lc_r) with -pthread.  I installed libkse as libpthread and made the
 appropriate links and built X and KDE and there were a lot of
 binaries that were linked to both libc_r and libpthread.

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_PRELOAD wins
above all.  If one threads library exports a symbol not in the others,
I'd call that an API bug in the first library.

This should be no different from explicitly linking in dmalloc to
override the malloc functions in libc, for example.

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 LD_PRELOAD wins above all. 
 If one threads library exports a symbol not in the others, I'd call that
 an API bug in the first library. 
 
 This should be no different from explicitly linking in dmalloc to
 override the malloc functions in libc, for example. 

One potential downside to the LD_PRELOAD approach is that it will only
work for applications that aren't setuid/setgid.  While today most of our
privileged and credential-munging applications aren't threaded, I'd like
to avoid precluding that in the future as much as possible.  What
mechanism should be used when LD_PRELOAD is being ignored due to
issetugid() returning true?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 ports so that
 they are PTHREAD_LIBS compliant (they would break when linked).
 I know it has no bearing on 3rd party stuff.
 
 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 want to make -pthread mean libkse,
 create an /etc/pthread.libs that looks like:

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 fileexists(libthr) then LDFLAGS += -lthr
* elseif fileexists(libc_r) then LDFLAGS += -lc_r
* else error(Threading not supported.)

or whatever.  At that point, simply having PTHREADS_LIBS moved into the
environment in bsd.port.mk and leaving all the ports using -pthread
alone would automatically have them support PTHREADS_LIBS.  Even better,
the existing bsd.port.mk construct could become just another pre-defined
environment variable, similar to LD_PRELOAD for the runtime linker, but
which affects the compiler/link editor instead.

--Mike



pgp0.pgp
Description: PGP signature

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 of that.
  
  That just meant it makes it easier to maintain ports so that
  they are PTHREAD_LIBS compliant (they would break when linked).
  I know it has no bearing on 3rd party stuff.
  
  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 want to make -pthread mean libkse,
  create an /etc/pthread.libs that looks like:
 
 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:
  
I should point out that my main concern here is not technical but
policy.  Right now -pthread is implemented entirely as a gcc spec as
part of LIB_SPEC.  I didn't have time to get very far so I'm not sure
how much special-case argument handling is done in gcc currently.  Would
this kind of approach, to moving the -pthread handling out of a
specfile and into args handling code, fly with the FSF people?

--Mike



pgp0.pgp
Description: PGP signature

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 precisely how it works.  `c99
 foo.c -l m' means `link in the math functions, wherever they may
 happen to live'.  Likewise `-l rt' for realtime -- and (relevant to
 this discussion) `-l pthread' for threads.  There is no requirement
 that any of these libraries exist as such.

That may be true, but these libraries don't have gcc options like
'-pthread' does to have them linked against. Why should a threaded library
be any different than libz, libpng or libwhatever your binary wants?

 Andre Guibert de Bruet | Enterprise Software Consultant 
 Silicon Landmark, LLC. | http://siliconlandmark.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 -current for well over 2 years.  Indeed, if you build KDE
and X with libpthread installed, you will see binaries that
are linked to both libc_r and libpthread.
   
   I can't see how this behaviour would not be considered a bug, if it
   is indeed true.  Are you saying that there are packages out there
   that will detect both -lpthread and -pthread and attempt to use
   both on the compilers and linker lines?
  
  Yes, it's not just that.  They can also find libc_r and include that
  (-lc_r) with -pthread.  I installed libkse as libpthread and made the
  appropriate links and built X and KDE and there were a lot of
  binaries that were linked to both libc_r and libpthread.
 
 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_PRELOAD wins
 above all.  If one threads library exports a symbol not in the others,
 I'd call that an API bug in the first library.

Yes, it does matter.  There are no problems with exported pthread
symbols that I know of.  I believe it is private symbols (__foo)
that are causing problems and C++ style autoinit that is needed
to initialize the libraries.

We don't want applications to link to multiple thread
libraries anyways.  I don't know how to prevent it...

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 want to make -pthread mean libkse,
 create an /etc/pthread.libs that looks like:

Kudos to you! That's the general direction of my thoughts, but I had no
idea where to look in gcc's guts...

And I agree, maybe it's not the best option, but we should at least
consider it.

Bye,
Andrea

-- 
Failure is not an option. It comes bundled with your Microsoft product.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 libc_r, what happens?

This is why its important to use the same name for the threading library
and never link directly with libkse, libthr, libc_r etc.  Make libpthread
a symlink, please.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 libpthread, and both are linked to
  libGL which is linked to libc_r, what happens?
 
 This is why its important to use the same name for the threading library
 and never link directly with libkse, libthr, libc_r etc.  Make libpthread
 a symlink, please.

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.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 what the SONAME entry says  It is technically
feasible to have libpthread.so by a symlink, provided that all three
thread libraries cooperate by announcing an SONAME of libpthread.so.N.

-GAWollman

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 that.
  
  That just meant it makes it easier to maintain ports so that
  they are PTHREAD_LIBS compliant (they would break when linked).
  I know it has no bearing on 3rd party stuff.
  
  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 want to make -pthread mean libkse,
  create an /etc/pthread.libs that looks like:
 
 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 fileexists(libthr) then LDFLAGS += -lthr
 * elseif fileexists(libc_r) then LDFLAGS += -lc_r
 * else error(Threading not supported.)

Out of all the suggestions (aside from making -pthread a NOOP),
this is my favorite one.  I would also make -pthread a NOOP
when building shared  dynamic.

I plan on changing thread library compatibility for FreeBSD
6.0, though.  So it might be wise just to add a different
compiler switch for libthr or libc_r.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 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 would break when linked).
   I know it has no bearing on 3rd party stuff.
   
   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 want to make -pthread mean libkse,
   create an /etc/pthread.libs that looks like:
  
  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 fileexists(libthr) then LDFLAGS += -lthr
  * elseif fileexists(libc_r) then LDFLAGS += -lc_r
  * else error(Threading not supported.)
 
 Out of all the suggestions (aside from making -pthread a NOOP),
 this is my favorite one.  I would also make -pthread a NOOP
 when building shared  dynamic.

I didn't think of it, but something like this also lets
me set PTHREAD_LIBS to  which would effectively become
a NOOP.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 platforms.
On some systems it also implies -D_REENTRANT and other flags as well.

-pthread cannot go away.  We'd just be hurting ourselves for no good reason,
especially when the rest of the world is syncing up with us.

Samples from http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog:


* config/linux.h (LIB_SPEC): If -pthread, add -lpthread even if
-shared.
* config/alpha/linux-elf.h (LIB_SPEC): Likewise.

* config/ia64/hpux.h: Define CPP_SPEC to set appropriate
#defines for -pthread.  Add -lpthread to LIB_SPEC when
-pthread.  In both cases take -mt as a synonym for -pthread
for acc compatibility.
... 
* config/netbsd.h: Update copyright years.
(NETBSD_CPP_SPEC): Define _REENTRANT and _PTHREADS if
-pthread is specified on the command line.
...


Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 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
   -pthread when compiling them from source myself. Not in the slightest.
   This is BAD BAD BAD for usability.
  
   Sincerely,
   Dan Naumov
  
   I also believe that a question has to be asked, what do the -core and
   -arch people think of all this ? I think that they should have the
   final say in the matter.
 
  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?  The fact that functions live in libraries and that
  to get access to said functions you link with said libraries has been
  the practice on Un*x for longer than I've been alive.  Please, people,
  let the -pthread hack die and just use -lmumble thread library.
  I think any FreeBSD-specific -pthread bits should just be removed
  and have the compiler complain about a bogus option.  If gcc chooses
  to have a machine independent -pthread (or -thread) to turn on TLS or
  some such, that's great and all, but that would be gcc code, not
  FreeBSD-specific code.

 Where were you a few days ago!

I definitly agree with Dan, -pthread is too ugly, it really really is
nothing to do with compiler and should be removed. If someone thinks -pthread
should be kept, then think about Microsoft, you are doing Microsoft way and
cause lots of trouble when I am programmming on Windows, Microsoft has two 
version of c library, threaded library and non-threaded library, it need a 
compiler flag -MT to link a thread library, then lots of library conflict
with this flag at linking time because some were compiled with -MT some were
not, this is rather annoying. This is a bit OT, but I hope we can avoid such
decision bug. Many software use autoconf, autconf prefers -lpthread than 
-pthread, it even prefers -lc_r then -pthread (if I remembered it right ).
if system has a libpthread there, it will generate Makefile to use -lpthread
not -pthread, obviously -pthread is not suggested to use.
One word, just let -pthread die.

David Xu

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 fileexists(libthr) then LDFLAGS += -lthr
* elseif fileexists(libc_r) then LDFLAGS += -lc_r
* else error(Threading not supported.)

Hello Mike,

I too thought about making -pthread an exact alias for
env(PTHREADS_LIBS) (and, if empty, pick -lpthread or the classic
default -lc_r).  The main issue is that the FSF gcc has not accepted
any code into the gcc driver which depends on environment variables.

Loren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 fileexists(libpthread) then LDFLAGS += -lpthread
 * elseif fileexists(libthr) then LDFLAGS += -lthr
 * elseif fileexists(libc_r) then LDFLAGS += -lc_r
 * else error(Threading not supported.)
 
 Hello Mike,
 
 I too thought about making -pthread an exact alias for
 env(PTHREADS_LIBS) (and, if empty, pick -lpthread or the classic
 default -lc_r).  The main issue is that the FSF gcc has not accepted
 any code into the gcc driver which depends on environment variables.

What is FSF gcc policy with regard to having multiple
thread switches, ala Solaris?  An alternative would be
to retain -pthread = -lc_r and switch it over to -lpthread
once sparc64 and alpha ports are done, then add a -thread
switch for -lthr if folks want similar treatment for libthr.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 to fix.  It's not like we're making
  someone change their code to accomodate library or
  kernel interface changes.
  
 
 This is exactly the case the is going to cause the problems, though.
 For you, compiling a 3rd party app and dealing with failures in the
 linker is easy to deal with.  For someone else, it might not be.  If
 they go to compile an app and it compiles and runs fine on linux but
 fails on FreeBSD with linker errors, it will likely leave a negative
 impression in their mind.
 
 I'm comparing my arguments to linux because a lot more apps are written
 with linux in mind than with solaris in mind these days.  People who are
 writing for linux or switching from linux might not know that
 '-lpthread' is a requirement, but they are more likely to know that
 '-pthread' will take care of all of that magic for them.  This argument
 really comes down to ease of use and user experience.  Steering away
 from de-facto standards steers us away from a positive user and
 developer experience.
 
 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.

I stand by my opinion.  Also, you may end up breaking more
things if -pthread causes libpthread to be linked in.  Applications
that want to link with libthread (1:1), libc_r, or libthr
and use -pthread with -lpthread1:1, -lc_r, or -lthr will
break.  And it won't be obvious until weird things happen
when they run.

You guys are assuming this is going to cause large problems.
Just wait and see.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 is the stated collective opinion
of the FSF gcc development team that -pthread should exist for all gcc
ports which support POSIX threads.  This is true even if not well
documented.  It would be best if adding the switch actually implied
everything to support threads.

If adding the -pthread switch is a NOOP to gcc but users could later
add (e.g.): LD_PRELOAD=libc_r.so (or one of the newer choices) and not
break anything, then I think that would be fully acceptable and meet
the specification of the switch.  This would be very cool in that you
could test/run against multiple thread libraries without a re-link.

If adding the -pthread switch is a NOOP to gcc but users must also add
-lc_r (or one of the newer choices) for correct operation, then I
think making it a NOOP is a bad idea and I attempted to state so.

Regards,
Loren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 my full advice.
 
 In my view (and thus my advice), it is the stated collective opinion
 of the FSF gcc development team that -pthread should exist for all gcc
 ports which support POSIX threads.  This is true even if not well
 documented.  It would be best if adding the switch actually implied
 everything to support threads.
 
 If adding the -pthread switch is a NOOP to gcc but users could later
 add (e.g.): LD_PRELOAD=libc_r.so (or one of the newer choices) and not
 break anything, then I think that would be fully acceptable and meet
 the specification of the switch.  This would be very cool in that you
 could test/run against multiple thread libraries without a re-link.

Yes, and I agree.  If someone were to tell me how to implement
that, I would do it.  If it is just a matter of adding some missing
pthread interfaces as stubs to libc, then it is pretty simple.

 If adding the -pthread switch is a NOOP to gcc but users must also add
 -lc_r (or one of the newer choices) for correct operation, then I
 think making it a NOOP is a bad idea and I attempted to state so.

Well, if they don't use LD_PRELOAD=libc_r.so or whatever and
try to run the application, it isn't going to work very well
using pthread stubs.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 where '-pthread' does anything other than generate
an error, it causes the compiler to conform to the pthreads standard.
FreeBSD will be the only platform that knows what '-pthread' is but doesn't
do the right thing when it gets it.

Isn't it good to have one flag that, on every platform that supports it,
gives you whatever's needed to get the default pthreads implementation to
work? And isn't that what '-pthread' was supposed to be for?

 Why do you want to shoehorn -pthread onto us when it is not
 a good fit?

Then don't support it. Return an error and nothing will break. 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.

There is a push to make all platforms that support pthreads support
'-pthread' to provide the needed compiler/linker goo to make pthreads work.
This move is a slap in the face against that standardization effort. It
means that configuration scripts will have to special case FreeBSD's current
behavior. And in the future, if FreeBSD threading libraries start requiring
compiler goo, they'll have to special case again. Another imcompatible
definition for the same compiler flag is a slap in the face to the effort to
standardize the meaning of the '-pthread' flag.

This is, I realize, turning into a bikeshed. This is cut down from a much
longer reply that I wrote while downloading email that made most of the
other points I was going to make.

DS


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 other platform. On every
 other platform I know of where '-pthread' does anything other than generate
 an error, it causes the compiler to conform to the pthreads standard.
 FreeBSD will be the only platform that knows what '-pthread' is but doesn't
 do the right thing when it gets it.
 
   Isn't it good to have one flag that, on every platform that supports it,
 gives you whatever's needed to get the default pthreads implementation to
 work? And isn't that what '-pthread' was supposed to be for?
 
  Why do you want to shoehorn -pthread onto us when it is not
  a good fit?
 
   Then don't support it. Return an error and nothing will break.

You have the support of the threads guys here, including jb.  But
we've been pushed the other way.

 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.

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 automatically link to libpthread gives preference to
it over libthr (or libthread (KSE in 1:1 mode) or libc_r).

Pros:
  o Allows us to define macros common to all the threads libraries.
  o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that
are not dependent on a particular threads library, but will use
whatever threads library the application uses (i.e., you want mplayer
to use libpthread and ogle to use libthr).
  o If we support LD_PRELOAD properly, will allow us to select the
threads library without having to rebuild/relink the application.
  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 build KDE and X with libpthread installed,
you will see binaries that are linked to both libc_r and libpthread.
  o Makes it easier to spot ports that are not PTHREAD_LIBS compliant.

Cons:
  o Third party applications that use -pthread exclusively (without
linking to a threads library) will have to add a link option.

I understand that folks want to wave their hands and say just make
-pthread work and do whatever it needs to.  I'm like that myself.
I just don't think it's a good idea.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 -pthread
when compiling them from source myself. Not in the slightest. This is
BAD BAD BAD for usability.

Sincerely,
Dan Naumov

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 around the source of 3rd-party applications that use -pthread
 when compiling them from source myself. Not in the slightest. This is
 BAD BAD BAD for usability.
 
 Sincerely,
 Dan Naumov

I also believe that a question has to be asked, what do the -core and
-arch people think of all this ? I think that they should have the final
say in the matter.

Sincerely,
Dan Naumov

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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.
However recent expirence shows that a 1:n model seems to be the
one the world over you is gearing around: Linux never did anything else.
Windows anyway. Solaris switched from n:m to 1:n on the step between
version 8 and 9 Having two of them isn't the solution for me as a developer
since I'm simply not interresed in debugging both cases.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 hacking around the source of 3rd-party applications
 that use -pthread when compiling them from source myself. Not in
 the slightest. This is BAD BAD BAD for usability.

I have to admit here that I know about -pthread only what I've been 
following in this ongoing thread.

I'm an end user that's run into the recent changes in pthreads causing 
breakage in ports (well one particular port, clamav).  I was able to 
figure out how to disable pthreads and hack the port to get it 
compiled and running, but it was rather annoying.  And having 
followed questions for a few years, I can easily imagine the kind of 
traffic that this behaviour will generate.  While the notion of 
knowlegeable folks being able to link in the thread library of choice 
sounds nice, does it really make sense to break what will be expected 
behaviour?

-Mark

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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.

I followed the whole thread and probably I'm being dense, but I still can't
get this point. Note that I'm not taking position one way or the other, just
asking.

Why is that so? Isn't it possible to have -pthread:

 - do nothing when linking libraries
 - use libmap.conf(5) (possibly integrated by whatever env magic we want to
add to allow this to be temporarily overridden) to decide what to link with.

Bye,
Andrea

-- 
   Press every key to continue.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

2003-09-23 Thread mike

On Tue, 23 Sep 2003, Daniel Eischen wrote:

 Date: Tue, 23 Sep 2003 16:13:11 -0400 (EDT)
 From: Daniel Eischen [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: David Schwartz [EMAIL PROTECTED]
 Cc: Doug Barton [EMAIL PROTECTED], Freebsd Current [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:
- libpthread (aka libkse) is the primary threading library under FreeBSD.
- libpthread gets linked agains unsing -pthread
- The user can use whatever he wants instead of libpthread using
  /etc/libmap.conf
- If libpthread should prove to have shortcomings it gets fixed or replaced
  by better software

Bye/2
---
Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consulting
Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED]
  http://www.plaut.de   |   http://www.Reifenberger.com

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 have to decide what the therading lib should be indeed.
 However recent expirence shows that a 1:n model seems to be the
 one the world over you is gearing around: Linux never did anything else.
 Windows anyway. Solaris switched from n:m to 1:n on the step between
 version 8 and 9 Having two of them isn't the solution for me as a developer
 since I'm simply not interresed in debugging both cases.

This is a reason why -pthread shouldn't imply linking
to any one library.  If you only want to deal with
libthr or libthread (KSE in 1:1 mode), then you are
free to choose them and only them.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 their
   installation.
  
  You can't make it variable.
 
 I followed the whole thread and probably I'm being dense, but I still can't
 get this point. Note that I'm not taking position one way or the other, just
 asking.
 
 Why is that so? Isn't it possible to have -pthread:
 
  - do nothing when linking libraries

This could and should be done.

  - use libmap.conf(5) (possibly integrated by whatever env magic we want to
 add to allow this to be temporarily overridden) to decide what to link with.

No, you can't do that.  You're welcome to try.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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
sanely.
You have to decide what the therading lib should be indeed.
However recent expirence shows that a 1:n model seems to be the
one the world over you is gearing around: Linux never did anything else.
Windows anyway. Solaris switched from n:m to 1:n on the step between
version 8 and 9 Having two of them isn't the solution for me as a developer
since I'm simply not interresed in debugging both cases.


This is a reason why -pthread shouldn't imply linking
to any one library.  If you only want to deal with
libthr or libthread (KSE in 1:1 mode), then you are
free to choose them and only them.
Last time I heard that this is a link time option. So you are supposed
to change the lib under the hood of the applications controll.
Making -ptherad empty is silly. If you are going to disable this
perfectly sensible compiler switch then BY EVERY MEANS better make it BREAK
CYRING ABOUT THIS FACT. But don't just silent it



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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, I strongly believe that we need to also treat -pthread
 sanely.
 
 You have to decide what the therading lib should be indeed.
 However recent expirence shows that a 1:n model seems to be the
 one the world over you is gearing around: Linux never did anything else.
 Windows anyway. Solaris switched from n:m to 1:n on the step between
 version 8 and 9 Having two of them isn't the solution for me as a developer
 since I'm simply not interresed in debugging both cases.
  
  
  This is a reason why -pthread shouldn't imply linking
  to any one library.  If you only want to deal with
  libthr or libthread (KSE in 1:1 mode), then you are
  free to choose them and only them.
 
 Last time I heard that this is a link time option. So you are supposed
 to change the lib under the hood of the applications controll.

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.

 Making -ptherad empty is silly. If you are going to disable this
 perfectly sensible compiler switch then BY EVERY MEANS better make it BREAK
 CYRING ABOUT THIS FACT. But don't just silent it

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.

(*) Unless we want to support LD_PRELOAD being able
to change the threads library.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 (isn't this what libmap.conf is supposed to
  help with)?
  
  Doug
  
 
 I have to agree with this.  '-pthread' seems to have taken on the
 meaning of 'turn on whatever magic makes the pthreads library work'.
 The application writer is allowed to focus on the application, not
 the FreeBSD-specific threading library options.  The user is allowed
 to compile a third-party app without having to worry about the
 FreeBSD-specific threading library options.  Everyone wins.

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, or configure script, will find libpthread
and all should be fine.

 If we take the stand that any software that uses '-pthread' is broken
 and should be fixed by the author, it will make FreeBSD wildly
 unpopular.  If we take the stand that the only sactioned way to
 compile a third-party app in FreeBSD is via the ports system, then
 FreeBSD will become much less usable.

There will be a libpthread and -pthread will be NOOP'd.  It
should be a very familiar environment.

 I've tried to stay silent on this issue in hopes that it would work
 itself out, but I'm not quite sure that it is.  Making FreeBSD harder
 to use and harder to program for in the name of pendanticy is not the
 best direction.

As I've said in a previous email, Solaris doesn't have -pthread
and it hasn't seemed to cause any problems.  If you are going
to have -pthread (libpthread), -thread (libpthread1:1),
-thr (libthr), -uthread (libc_r), this is no different than
making them the appropriate link arguments.

There should be very little problem for 3rd party applications.
-pthread won't cause an error.  If there is any problem, it
will be on the link command and it should be very obvious
that a threading library wasn't pulled in.  Since a libpthread
will be present on the system, it's pretty much a no-brainer
how to fix the problem.

This is not like we're changing kernel or library interfaces.
I think folks are making a bigger deal out of it than it
really is.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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, or configure script, will find libpthread
 and all should be fine.

No, most people only fall back on trying to figure out what threading
library to link to if '-pthread' causes an error.

 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 flag
is supplied?

 As I've said in a previous email, Solaris doesn't have -pthread
 and it hasn't seemed to cause any problems.  If you are going
 to have -pthread (libpthread), -thread (libpthread1:1),
 -thr (libthr), -uthread (libc_r), this is no different than
 making them the appropriate link arguments.

Yes, but it returns an error when '-pthread' is supplied.

 There should be very little problem for 3rd party applications.
 -pthread won't cause an error.

That's the problem. This will dupe configuration scripts into believing
that the option is supported.

 If there is any problem, it
 will be on the link command and it should be very obvious
 that a threading library wasn't pulled in.  Since a libpthread
 will be present on the system, it's pretty much a no-brainer
 how to fix the problem.

Yes, by either removing the '-pthread' flag or making it work.

 This is not like we're changing kernel or library interfaces.
 I think folks are making a bigger deal out of it than it
 really is.

The whole point of '-pthread' is to provide one standardized way to easily
figure out what magic compiler/linker flags you need so you don't have to
special case every platform. However, you are suggesting behavior for this
flag that is unlike any other platform, turning the stardization attempt on
its head.

DS


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 flag
 is supplied?

No.  There are other environments that don't have -pthread
though.

  As I've said in a previous email, Solaris doesn't have -pthread
  and it hasn't seemed to cause any problems.  If you are going
  to have -pthread (libpthread), -thread (libpthread1:1),
  -thr (libthr), -uthread (libc_r), this is no different than
  making them the appropriate link arguments.
 
   Yes, but it returns an error when '-pthread' is supplied.
 
  There should be very little problem for 3rd party applications.
  -pthread won't cause an error.
 
   That's the problem. This will dupe configuration scripts into believing
 that the option is supported.

No, some scripts use both -pthread and -lpthread together
already (on Linux!).  I just checked the configure script
in kdebase-3.1.3.  The threads library check seems to be
independent of the compiler check.  To test this, I made
a link from /usr/lib/libpthread.so to /usr/lib/libkse.so
and manually ran the configure script.  It worked just
fine.  It picked up -lpthread and didn't use -pthread (on
this system, -pthread still worked).

 
  If there is any problem, it
  will be on the link command and it should be very obvious
  that a threading library wasn't pulled in.  Since a libpthread
  will be present on the system, it's pretty much a no-brainer
  how to fix the problem.
 
   Yes, by either removing the '-pthread' flag or making it work.

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.

 
  This is not like we're changing kernel or library interfaces.
  I think folks are making a bigger deal out of it than it
  really is.
 
   The whole point of '-pthread' is to provide one standardized way to easily
 figure out what magic compiler/linker flags you need so you don't have to
 special case every platform. However, you are suggesting behavior for this
 flag that is unlike any other platform, turning the stardization attempt on
 its head.

Why do you want to shoehorn -pthread onto us when it is not
a good fit?

We don't have one standard library.  The example I like to
use is Solaris.  They have 2 thread libraries and have a
compiler switch for each one (-pthreads and -threads,
note -pthreads != -pthread).  Probably the reason they
have a compiler switch in the first place is because they
need to define __REENTRANT; FreeBSD doesn't need to
define anything.  If you are going to have more than
one compiler switch, then it defeats the purpose for it
because you might just as well use the correct link command.

Don't think about ports.  We have to make them PTHREAD_LIBS
compliant so the user can select a different library.  If
you want to argue that, then start another discussion
on ports about it.

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 their code to accomodate library or
kernel interface changes.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 their code to accomodate library or
kernel interface changes.
This is exactly the case the is going to cause the problems, though.
For you, compiling a 3rd party app and dealing with failures in the
linker is easy to deal with.  For someone else, it might not be.  If
they go to compile an app and it compiles and runs fine on linux but
fails on FreeBSD with linker errors, it will likely leave a negative
impression in their mind.
I'm comparing my arguments to linux because a lot more apps are written
with linux in mind than with solaris in mind these days.  People who are
writing for linux or switching from linux might not know that
'-lpthread' is a requirement, but they are more likely to know that
'-pthread' will take care of all of that magic for them.  This argument
really comes down to ease of use and user experience.  Steering away
from de-facto standards steers us away from a positive user and
developer experience.
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.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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.
 This is trivial to fix.  It's not like we're making
 someone change their code to accomodate library or
 kernel interface changes.
 
 
 This is exactly the case the is going to cause the problems, though.
 For you, compiling a 3rd party app and dealing with failures in the
 linker is easy to deal with.  For someone else, it might not be.  If
 they go to compile an app and it compiles and runs fine on linux but
 fails on FreeBSD with linker errors, it will likely leave a negative
 impression in their mind.
 
 I'm comparing my arguments to linux because a lot more apps are written
 with linux in mind than with solaris in mind these days.  People who are
 writing for linux or switching from linux might not know that
 '-lpthread' is a requirement, but they are more likely to know that
 '-pthread' will take care of all of that magic for them.  This argument
 really comes down to ease of use and user experience.  Steering away
 from de-facto standards steers us away from a positive user and
 developer experience.
 

If the behavior of -pthread is documented in the man pages,
then your argument holds no water.  If the link stage fails,
one would hope that the user can read the documention.

-- 
Steve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 threads library.
This is trivial to fix.  It's not like we're making
someone change their code to accomodate library or
kernel interface changes.
This is exactly the case the is going to cause the problems, though.
For you, compiling a 3rd party app and dealing with failures in the
linker is easy to deal with.  For someone else, it might not be.  If
they go to compile an app and it compiles and runs fine on linux but
fails on FreeBSD with linker errors, it will likely leave a negative
impression in their mind.
I'm comparing my arguments to linux because a lot more apps are written
with linux in mind than with solaris in mind these days.  People who are
writing for linux or switching from linux might not know that
'-lpthread' is a requirement, but they are more likely to know that
'-pthread' will take care of all of that magic for them.  This argument
really comes down to ease of use and user experience.  Steering away
from de-facto standards steers us away from a positive user and
developer experience.


If the behavior of -pthread is documented in the man pages,
then your argument holds no water.  If the link stage fails,
one would hope that the user can read the documention.
Many, many, many things that are documented in the man pages still
generate questions and frustration.  Adding an extra learning step
is not the best way to make the OS more usable.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

2003-09-21 Thread Will Andrews

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 that need to
 be fixed (in fact I already have this, see
 http://dosirak.kr.freebsd.org/errorlogs).
 
 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 or do whatever else is decided to be
 appropriate.
 
 4) It is likely that steps 2 and 3 will need to be iterated several
 times, because there are dozens of ports that need to be fixed, and
 many of them are hiding other ports that depend on them and also need
 to be fixed.

I don't know if there is much point to #1 at this point since
it's been gone for about 2 weeks now.  #2/3/4 sounds fine to me.

In the meantime KF is working on a patch to properly support
PTHREAD_LIBS in KDE's configure scripts.  We plan to commit it
when the freeze lifts, pending PR #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/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 instead of asserting, because that's
 getting us nowhere towards resolving this.

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/2003/freebsd-ports/20030601.freebsd-ports

my posting to ports@ in May of this year.

When the GCC-3.3 import broke a lot of ports, did you ask for it to
be backed out so that ports could first be fixed?  Yeah, OK, we're
in a ports freeze, so that's different now.  But once the freeze
is lifted, I don't see a need to keep -pthread in (assuming it
was added back for the freeze).

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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:
 
   
 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports
 
 my posting to ports@ in May of this year.

I wish you'd pushed the issue a bit more aggressively.  Sometimes
people don't pay close enough attention, and I am definitely one
of those people.  My apologies for missing that message.

Regards,
-- 
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 helps
much in fixing ports...

Again, why? Please explain instead of asserting, because that's
getting us nowhere towards resolving this.

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.

What's the real issue here? It seems like you're suggesting that it's
not your responsibility to help fix the broken ports, and that other
people should do the work instead.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports

my posting to ports@ in May of this year.

That change doesn't seem to have happened, or to be the same thing
we're discussing here. Anyway, if you'd been interested in
pre-empting problems with the -pthread change you could have asked me
to do a package build with the change in place to test the waters, and
then worked with me and others to minimize the impact at the time when
the commit went in. I routinely do this with other committers
(including the gcc imports), and I'm happy to continue doing so.

However, the strategy of just dumping a change into the tree and then
leaving it to others to clean up the mess is not a good one - it's
disruptive to the development cycle, it causes developers to get
bogged down in arguments like we find ourselves having now, and the
bottom line is that it's just not very polite to the people that your
change affects.

When the GCC-3.3 import broke a lot of ports, did you ask for it to
be backed out so that ports could first be fixed?

No, kan and I worked together before the change went in to evaluate
the impact on packages, then I coordinated a group of volunteers to
help fix the resulting fallout. I'm trying to do the same thing now.
Are you willing to be part of the solution to this problem?

Kris

pgp0.pgp
Description: PGP signature

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

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, and 3. I don't think backing out -pthread change helps
much in fixing ports...

Again, why? Please explain instead of asserting, because that's
getting us nowhere towards resolving this.

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.

What's the real issue here? It seems like you're suggesting that it's
not your responsibility to help fix the broken ports, and that other
people should do the work instead.

Well, sorta yes. I don't have the time to fix broken ports
but I can help guide others. I have other things on my plate.
I do have one of my own ports to fix though.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports

my posting to ports@ in May of this year.

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 up
using -pthread and/or PTHREAD_LIBS. If PTHREAD_LIBS is set
to libthr or libc_r (something other than libpthread), then
the port ends up linking to both libraries. This doesn't work
but you don't know it until your run the application and very
weird things happen. Causing a clean breakage is better because
you know at compile-time that something is wrong. So ports need to
first be PTHREAD_LIBS compliant before we make the switch. Soon
after ports are fixed, we can rename it.

I think doing a build of all the ports is a good idea.
I guess you've already done that if I recall an earlier
email correctly. I also think most of the problems are
already known, and if you give it a few days after the
freeze things should look a lot better.

Actually, to look ahead a bit... After ports are fixed, it
still might be a good idea to do another package build, but
this time with libkse installed as libpthread and PTHREAD_LIBS
set to libc_r (or something that is not libpthread). Is there
an easy way to do an 'ldd' of the resulting binaries to
make sure libpthread isn't referenced? Feel free to take
this offline if you want...

As Will mentioned, I think the changes are mostly done. I
don't think I just 'dumped' the changes into the tree. It
has been over 2 years since, yada yada yada, and the ports
system should have been using PTHREAD_LIBS since then. I don't
want to argue with you; I respect you and everyone else here
and God knows you guys contribute an awful lot.

When the GCC-3.3 import broke a lot of ports, did you ask for it to
be backed out so that ports could first be fixed?

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.

--
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 think we are going to extend it to allow more fixes for 4.9
since it's going to be delayed.  But I'm not positive.

Regards,
-- 
wca
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 run its course.

Executive summary: POLA was violated for all the ports maintainers
who do not keep up with kernel intricacies.  Dismissing their
distress at this doesn't really help the project move along.

mcl

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 the release is cut.

IMHO, what you think just doesn't reflect the actual reality
involved.  We are just going to have to disagree on this.

You should really look at the bento logs and get an understanding
of the continual QA that is done on the _over_ 9000 ports (many
of which have _no_ maintainer signed up) before you make assumptions
that there shouldn't be significant problems with what you propose.

mcl


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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,
  I'll back the change out until it's over.
 
 I think we are going to extend it to allow more fixes for 4.9
 since it's going to be delayed.  But I'm not positive.

OK, instead of waiting for it to be delayed, I backed out the
-pthread removal until it's over.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 up
 using -pthread and/or PTHREAD_LIBS.  If PTHREAD_LIBS is set
 to libthr or libc_r (something other than libpthread), then
 the port ends up linking to both libraries.  This doesn't work
 but you don't know it until your run the application and very
 weird things happen.  Causing a clean breakage is better because
 you know at compile-time that something is wrong.  So ports need to
 first be PTHREAD_LIBS compliant before we make the switch.  Soon
 after ports are fixed, we can rename it.

Where the ports are concerned, I think this is a reasonable course of
action, and I'd like to thank you for backing out the -pthread change on
HEAD. 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?

Doug

-- 

This .signature sanitized for your protection

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 -lpthread).

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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,
  autoconf/configure will pick it up and the port will also end up
  using -pthread and/or PTHREAD_LIBS.  If PTHREAD_LIBS is set
  to libthr or libc_r (something other than libpthread), then
  the port ends up linking to both libraries.  This doesn't work
  but you don't know it until your run the application and very
  weird things happen.  Causing a clean breakage is better because
  you know at compile-time that something is wrong.  So ports need to
  first be PTHREAD_LIBS compliant before we make the switch.  Soon
  after ports are fixed, we can rename it.
 
 Where the ports are concerned, I think this is a reasonable course of
 action, and I'd like to thank you for backing out the -pthread change on
 HEAD. 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'll have to choose one of our threading libraries.
-pthread will be a NOOP for them, so their application
will fail to link.

If the third party application is a library, it won't be as
obvious because it won't cause a compile or link error.  This
holds true for ports also.  It might not be that much of a
problem though, because applications that link to the third
party library can always link to whatever threads library
they want.  Then the third party library would end up using
the threads library chosen by the application.  This might
be the way to go for OpenGL or other similar libraries.  It
allows you to have applications linked with different thread
libraries and not be broken by OpenGL (or whatever) being
explicitly linked to a different threads library than the
application.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 their thread library of choice
 (e.g. -lc_r or -lpthread).

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 (isn't this what libmap.conf is supposed to
help with)?

Doug

-- 

This .signature sanitized for your protection

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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$ uname -a
  SunOS pcnet5 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-2
  bash-2.05$ type cc
  cc is hashed (/usr/ucb/cc)
  bash-2.05$ type gcc
  gcc is hashed (/usr/local/bin/gcc)
  bash-2.05$ cc -pthread
  cc: unrecognized option `-pthread'
  cc: No input files
  bash-2.05$ gcc -pthread
  gcc: unrecognized option `-pthread'
  gcc: No input files

gcc does have -pthreads and -threads for Solaris, but these are
basically NOOPs (just what we are doing).  They define
-D_REENTRANT -D_PTHREADS for -pthreads and -D_REENTRANT
and -D_SOLARIS_THREADS for -threads.  These do not specify
any libraries to link, just predefines.  FreeBSD doesn't
have anything to predefine, so it is a true NOOP.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 platforms would be?
 
 Solaris for one:
 
   bash-2.05$ uname -a
   SunOS pcnet5 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-2
   bash-2.05$ type cc
   cc is hashed (/usr/ucb/cc)
   bash-2.05$ type gcc
   gcc is hashed (/usr/local/bin/gcc)
   bash-2.05$ cc -pthread
   cc: unrecognized option `-pthread'
   cc: No input files
   bash-2.05$ gcc -pthread
   gcc: unrecognized option `-pthread'
   gcc: No input files
 
 gcc does have -pthreads and -threads for Solaris, but these are
 basically NOOPs (just what we are doing).  They define
 -D_REENTRANT -D_PTHREADS for -pthreads and -D_REENTRANT
 and -D_SOLARIS_THREADS for -threads.  These do not specify
 any libraries to link, just predefines.  FreeBSD doesn't
 have anything to predefine, so it is a true NOOP.

Actually, it does look like the Solaris -threads and -pthreads
options do imply linking to -lthread and -lpthread respectively
(when not building with -shared).  But regardless, -threads and
-pthreads are not portable.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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 -pthread with their thread library of choice
(e.g. -lc_r or -lpthread).


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 (isn't this what libmap.conf is supposed to
help with)?
Doug

I have to agree with this.  '-pthread' seems to have taken on the
meaning of 'turn on whatever magic makes the pthreads library work'.
The application writer is allowed to focus on the application, not
the FreeBSD-specific threading library options.  The user is allowed
to compile a third-party app without having to worry about the
FreeBSD-specific threading library options.  Everyone wins.
If we take the stand that any software that uses '-pthread' is broken
and should be fixed by the author, it will make FreeBSD wildly
unpopular.  If we take the stand that the only sactioned way to
compile a third-party app in FreeBSD is via the ports system, then
FreeBSD will become much less usable.
I've tried to stay silent on this issue in hopes that it would work
itself out, but I'm not quite sure that it is.  Making FreeBSD harder
to use and harder to program for in the name of pendanticy is not the
best direction.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Fixing -pthreads (Re: ports and -current)

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 missed the reason why FreeBSD needs to be unique wrt threading
  programs and not have -pthread...
 
 Because -pthread allows selection of one specific threadling library,
 not multiple.  It is also unnecessary since the library is specified
 as a link option, not a compiler option.  In the future, -pthread
 will be a NOOP, but it suits us now to have it cause an error so
 that ports that don't honor PTHREAD_LIBS can be found and fixed.

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 that need to
be fixed (in fact I already have this, see
http://dosirak.kr.freebsd.org/errorlogs).

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 or do whatever else is decided to be
appropriate.

4) It is likely that steps 2 and 3 will need to be iterated several
times, because there are dozens of ports that need to be fixed, and
many of them are hiding other ports that depend on them and also need
to be fixed.

Kris


pgp0.pgp
Description: PGP signature

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 or do whatever else is decided to be
 appropriate.

OK, so what's the commit procedure going to be? This could generate an
awful lot of little PRs.

Scot posted a patch for bsd.port.mk. Is that going to be committed?
That's needed.

Are you prepared to unlock the ports tree and allow a blanket commit auth
for commits that only change patch-configure? That should catch most of
the simple cases.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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 they're all fixed, we can turn the error
  back on or make it a NOP or do whatever else is decided to be
  appropriate.
 
 OK, so what's the commit procedure going to be? This could generate an
 awful lot of little PRs.

Call for volunteers, take the list of failed ports from dosirak and
divide it up between yourselves, then mark off the ports as fixes are
developed.  The fixes can be committed once the freeze is over (and
they are demonstrated not to break on 4.x).

There's no reason this needs to be coordinated through GNATS, and
indeed that would probably be counter-productive.  Since it won't be
affecting people outside the testing group who continue to run a gcc
that treats -pthread as an error, duplicate or bogus PRs won't be
generated by people who aren't in the loop.

 Scot posted a patch for bsd.port.mk. Is that going to be committed?
 That's needed.

Sure, if it works.  I can test it once the current 5.x build finishes
on dosirak.

 Are you prepared to unlock the ports tree and allow a blanket commit auth
 for commits that only change patch-configure? That should catch most of
 the simple cases.

I'm unsure of the current status - the original schedule called for
the ports tree to be tagged yesterday, but now the schedule has
slipped.  marcus is in charge of this release, so he'll have to
comment on the updated timeline.  However, we need to be careful not
to destabilize 4.9 in committing hasty and poorly-tested fixes for
problems on -current that do not also work on 4.x (this is
unfortunately a common occurrence).

At any rate, 4.9 will be released sooner or later, and in following
step 1) of my proposal the only people the freeze will continue to
affect are those who are working on fixing the -pthread issues, which
can be kept in private repositories for a week or two.  For everyone
else, ports that use -pthread will go back to working again (modulo
pre-existing compile failures).

Kris

pgp0.pgp
Description: PGP signature

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 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 or do whatever else is decided to be
   appropriate.
  
  OK, so what's the commit procedure going to be? This could generate an
  awful lot of little PRs.
 
 Call for volunteers, take the list of failed ports from dosirak and
 divide it up between yourselves, then mark off the ports as fixes are
 developed.  The fixes can be committed once the freeze is over (and
 they are demonstrated not to break on 4.x).
 
 There's no reason this needs to be coordinated through GNATS, and
 indeed that would probably be counter-productive.  Since it won't be
 affecting people outside the testing group who continue to run a gcc
 that treats -pthread as an error, duplicate or bogus PRs won't be
 generated by people who aren't in the loop.
 
  Scot posted a patch for bsd.port.mk. Is that going to be committed?
  That's needed.
 
 Sure, if it works.  I can test it once the current 5.x build finishes
 on dosirak.
 
  Are you prepared to unlock the ports tree and allow a blanket commit auth
  for commits that only change patch-configure? That should catch most of
  the simple cases.
 
 I'm unsure of the current status - the original schedule called for
 the ports tree to be tagged yesterday, but now the schedule has
 slipped.  marcus is in charge of this release, so he'll have to
 comment on the updated timeline.  However, we need to be careful not
 to destabilize 4.9 in committing hasty and poorly-tested fixes for
 problems on -current that do not also work on 4.x (this is
 unfortunately a common occurrence).

I will most likely be tagging the tree sometime this week once things
have stabilized with the recent GNOME and KDE commits.  I do not want to
start having -pthread commits go in at this time as they do not help the
-STABLE build process.

Joe

 
 At any rate, 4.9 will be released sooner or later, and in following
 step 1) of my proposal the only people the freeze will continue to
 affect are those who are working on fixing the -pthread issues, which
 can be kept in private repositories for a week or two.  For everyone
 else, ports that use -pthread will go back to working again (modulo
 pre-existing compile failures).
 
 Kris
-- 
PGP Key : http://www.marcuscom.com/pgp.asc




signature.asc
Description: This is a digitally signed message part

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

2003-09-20 Thread Daniel Eischen

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 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...
  
  Because -pthread allows selection of one specific threadling library,
  not multiple.  It is also unnecessary since the library is specified
  as a link option, not a compiler option.  In the future, -pthread
  will be a NOOP, but it suits us now to have it cause an error so
  that ports that don't honor PTHREAD_LIBS can be found and fixed.
 
 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 that need to
 be fixed (in fact I already have this, see
 http://dosirak.kr.freebsd.org/errorlogs).
 
 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 or do whatever else is decided to be
 appropriate.
 
 4) It is likely that steps 2 and 3 will need to be iterated several
 times, because there are dozens of ports that need to be fixed, and
 many of them are hiding other ports that depend on them and also need
 to be fixed.

Just unfreeze the ports tree and allow broken ports to be
fixed.  Problem solved.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

2003-09-20 Thread Daniel Eischen

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 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 or do whatever else is decided to be
   appropriate.
  
  OK, so what's the commit procedure going to be? This could generate an
  awful lot of little PRs.
 
 Call for volunteers, take the list of failed ports from dosirak and
 divide it up between yourselves, then mark off the ports as fixes are
 developed.  The fixes can be committed once the freeze is over (and
 they are demonstrated not to break on 4.x).
 
 There's no reason this needs to be coordinated through GNATS, and
 indeed that would probably be counter-productive.  Since it won't be
 affecting people outside the testing group who continue to run a gcc
 that treats -pthread as an error, duplicate or bogus PRs won't be
 generated by people who aren't in the loop.
 
  Scot posted a patch for bsd.port.mk. Is that going to be committed?
  That's needed.
 
 Sure, if it works.  I can test it once the current 5.x build finishes
 on dosirak.
 
  Are you prepared to unlock the ports tree and allow a blanket commit auth
  for commits that only change patch-configure? That should catch most of
  the simple cases.
 
 I'm unsure of the current status - the original schedule called for
 the ports tree to be tagged yesterday, but now the schedule has
 slipped.  marcus is in charge of this release, so he'll have to
 comment on the updated timeline.  However, we need to be careful not
 to destabilize 4.9 in committing hasty and poorly-tested fixes for
 problems on -current that do not also work on 4.x (this is
 unfortunately a common occurrence).
 
 At any rate, 4.9 will be released sooner or later, and in following
 step 1) of my proposal the only people the freeze will continue to
 affect are those who are working on fixing the -pthread issues, which
 can be kept in private repositories for a week or two.  For everyone
 else, ports that use -pthread will go back to working again (modulo
 pre-existing compile failures).

Because -pthread has broken ports, fixes are already being
and have been developed.  Just unfreeze the tree or give
permission to commit -current breakage fixes (with the
caveat they are compile tested on -stable).

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

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]
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...
   
   Because -pthread allows selection of one specific threadling library,
   not multiple.  It is also unnecessary since the library is specified
   as a link option, not a compiler option.  In the future, -pthread
   will be a NOOP, but it suits us now to have it cause an error so
   that ports that don't honor PTHREAD_LIBS can be found and fixed.
  
  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 that need to
  be fixed (in fact I already have this, see
  http://dosirak.kr.freebsd.org/errorlogs).
  
  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 or do whatever else is decided to be
  appropriate.
  
  4) It is likely that steps 2 and 3 will need to be iterated several
  times, because there are dozens of ports that need to be fixed, and
  many of them are hiding other ports that depend on them and also need
  to be fixed.
 
 Just unfreeze the ports tree and allow broken ports to be
 fixed.  Problem solved.

Daniel, this is most unhelpful.  We're a week or two way from
releasing 4.9-RELEASE, and unfreezing now would lead to guaranteed
problems for the release (recall the point of having ports freezes in
the first place).

What, precisely, do you object to in the above proposal?

Kris


pgp0.pgp
Description: PGP signature

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

2003-09-20 Thread Daniel Eischen

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:

 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...

Because -pthread allows selection of one specific threadling library,
not multiple.  It is also unnecessary since the library is specified
as a link option, not a compiler option.  In the future, -pthread
will be a NOOP, but it suits us now to have it cause an error so
that ports that don't honor PTHREAD_LIBS can be found and fixed.
   
   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 that need to
   be fixed (in fact I already have this, see
   http://dosirak.kr.freebsd.org/errorlogs).
   
   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 or do whatever else is decided to be
   appropriate.
   
   4) It is likely that steps 2 and 3 will need to be iterated several
   times, because there are dozens of ports that need to be fixed, and
   many of them are hiding other ports that depend on them and also need
   to be fixed.
  
  Just unfreeze the ports tree and allow broken ports to be
  fixed.  Problem solved.
 
 Daniel, this is most unhelpful.  We're a week or two way from
 releasing 4.9-RELEASE, and unfreezing now would lead to guaranteed
 problems for the release (recall the point of having ports freezes in
 the first place).

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?  In a better world, freezing -stable
shouldn't hinder -current.

 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...

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

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