Re: ports and -current

On Sat, 20 Sep 2003, M. Warner Losh wrote:

> In message: <Pine.GSO.4.10.10309202038570.19227-100000_at_pcnet5.pcnet.com>
>             Daniel Eischen <eischen_at_vigrid.com> writes:
> : On Sat, 20 Sep 2003, M. Warner Losh wrote:
> : 
> : > In message: <3F6BF02F.9040707_at_schmalzbauer.de>
> : >             Harald Schmalzbauer <h_at_schmalzbauer.de> 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.
> 
> Why does -pthread necessarily force selection of one specific
> threading library?  All it means is that it is that the program uses
> posix threads, at least traditionally.  How FreeBSD causes that to
> happen is an interesting implementation detail for some, but irrelvant
> for most ports.  Couldn't -pthread be made to give the user the
> default threading package, and for those that matter a more specific
> one can be specified?

The default threading package when building in the ports
system is PTHREAD_LIBS.  You can't make -pthread select that.
PTHREAD_LIBS can be overridden in /etc/make.conf or the
environment.  If you want to argue between which you'd
prefer, PTHREAD_LIBS or -pthread, that's fine, but PTHREAD_LIBS
is what we currently have and what I'm going by.

> It is insane to have FreeBSD be different than all other systems for
> this trivial reason.  Why fix everthing in the world when allowing
> -pthread to be a noop would solve the problem?  Seems like we're being
> overly picky for no real gain.  I guess I just don't understand.

Allowing -pthread to be a noop doesn't necessarily solve the
problem right now.  Ports check for -pthread and use it
without also using PTHREAD_LIBS, so they would still be
broke.  Ports that are libraries that use -pthread won't
break when -pthread is NOOP'd, but non-threaded applications
that use those libraries may fail to link.

-- 
Dan Eischen