chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] PATCH: fix pthread on BSD


From: Peter Bex
Subject: Re: [Chicken-hackers] PATCH: fix pthread on BSD
Date: Sun, 2 Oct 2011 18:30:46 +0200
User-agent: Mutt/1.4.2.3i

On Sun, Oct 02, 2011 at 11:20:37AM +0200, Christian Kellermann wrote:
> The patch still makes sense for architectures with older gcc versions.
> I think we should test for it and wrap it then (this may also apply
> to the -fwrap switch).
> 
> How do other BSDs deal with this?

NetBSD uses "-lpthread" in its own buildlinking but pkgsrc uses -pthread.
The manpage for gcc only mentions -pthread under OS or hardware-specific
sections like HP-UX and SPARC.  It's never mentioned specifically as
being supported under NetBSD.

In a bit of inconsistency with the main system's build, NetBSD's native
package manager "pkgsrc" uses the "-pthread" option.
Since it's portable to other platforms than just NetBSD, it tries to
figure out what the OS is and only enables the "-pthread" option for
DragonFlyBSD, FreeBSD, Linux(!), MirBSD and NetBSD.  Strangely enough,
OpenBSD is not listed there, so I guess it'll fall back to using
"-lpthread" there.

> I would prefer to divert from the "mainstream" flags as little as possible.
> 
> What do you think?

I think we shouldn't change it if it isn't broken, and it seems this
patch was only submitted after reading the manual, seeing the option's
not listed and concluding it's therefore not officially supported; it
has always worked fine on OpenBSD AFAIK.

If we *must* change this, it's probably worth experimenting using the
-pthread flag everywhere (like the patch does), and seeing if this
breaks on any of the BSD platforms.

So no
 - if gcc version < 1.234
    options = this
 - elseif gcc version < 2.345
    options = -fwrap
 - else
    options = -fwrap -lpthread

That's just too painful to maintain.  Less conditionals in the build
system means more readable and maintainable code, and a more reliable
system in general.  It's bad enough already :/

Anyway, it's contained in the bsd-specific Makefile, so changing it
won't cause massive breakage; it *might* only affect a few.

Having said all this, the Makefile *with* patch works fine on NetBSD
as well so maybe it's all just a lot of fuss over nothing.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth



reply via email to

[Prev in Thread] Current Thread [Next in Thread]