Re: Of threads and OpenBSD

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

There is a general model for solving the common issues but most of the
issues discussed herein are solved on a per-port basis.  I suggest
cloning how the closest system does it (e.g. FreeBSD in your case).

> The threads implementation in OpenBSD is finally getting usable, so I am
> playing a bit with it and gcc-3.2.2.

> I've done --enable-threads=posix, but I'm running into issues.
> Specifically, OpenBSD needs to specify -pthread to the compiler to get
> threads issues resolved (to link with -lpthread, currently, whereas it

Yes, FreeBSD 5.x has the exact same linkage model for threads.

> used to link with -lc_r instead of -lc).

Yes, FreeBSD 4.x has the exact same linkage model for threads.

> The -pthread switch is a `final' switch: linking against -lpthread only
> happens on final programs, and not intermediate libraries (this wouldn't
> help, since on at least a few OpenBSD architectures, doing
> gcc -shared -o foo.so -lbar   will only make a final link complain that
> `-lbar is missing' if it's not mentionned there as well). There's also the
> issue that everything must be linked with -pthread for threads to work
> (e.g., the libc holds `weak' symbols for threaded stuff, and -lpthread can
> override them).

This sounds subtly different than either FreeBSD [45]; but it might be
the same.  However, you can support this model with the specs format.

> A large number of tests fail. Indeed, libstdc++ goes as far as failing on
> the abi test... and then most libstdc++, g++, objc tests fail.
> I could fix them manually by providing -pthread everywhere.

> Is there something I'm missing ?

Probably something very minor, you will have to look at the test suite
log to see what is actually failing in these cases (please post the
exact command lines run to link libstd++.so and then a failing test
case along with all compiler errors in that case).  Instead of
unconditionally adding -pthread everywhere, consider...

> I know that FreeBSD uses a fairly similar setup to ours (libc_r),
> and I haven't really found the required knobs.

When a port supports weak symbols and POSIX threads, libstdc++-v3 and
objc support building themselves in a mode where overhead for mutex
regions is dynamically inserted when the final link reveals that the
primary system thread library is provided non-weak.  It took multiple
years to tweak various ports to get this right.  libstdc++-v3 and objc
use the same solution; libjava uses its own threading abstraction
layer which doesn't provide this feature.  Find out why the
auto-detection of these features isn't working for OpenBSD.

> The way I see things, it's probably necessary for us to rebuild a few libs
> (libstdc++) in a multilib-like environment, and to take -pthread into
> accounts for a few other things (exception propagation ?).

Some ports do this because they don't support weak symbols ala ELF.
Please make libstdc++-v3 multilib to handle threading support as a
last resort.

> Is there already a framework, or am I doomed to doing it all ?

Well, if all related autoconf detection is working properly, your
platform supports ELF-like weak symbols and the base compiler is setup
properly to support threads (and reports `Thread model: posix'), then
libobjc and libstdc++-v3 should have worked out of the box without any
hacking.  The farther a platform iks from that, the most hacking you
would have to do.  Since I think OpenBSD matches the requirements, I'd
guess that autoconf detection of the situation or the base compiler
configuration is subtly broken.

Regards,
Loren