Re: libstdthreads threads.h detection and gnulib

On Thu, Sep 12, 2024 at 08:49:33AM +0200, Matthieu Herrb wrote:
> On Wed, Sep 11, 2024 at 10:51:50PM +0200, Antoine Jacoutot wrote:
> > On Wed, Sep 11, 2024 at 10:13:12PM +0200, Jeremie Courreges-Anglas wrote:
> > > (List found with grep '^checking for threads.h' on the latest amd64
> > > build logs.)
> > >
> > > I can think of several approaches to fix this:
> > >
> > > 1. add libstdthreads as a build dep to all those ports. Simple but
> > > slightly problematic:
> > > - IIUC, brings no functional value
> > > - increases the chance of libstdthreads being picked up by future ports
> > >
> > > 2. "poison" threads.h detection for gnu.port.mk ports. This should be
> > > enough for the gnulib occurences.
> > >
> > > 3. move libstdthreads header and libs to a subdirectory, to avoid
> > > threads.h being picked up just because it's in the commonly used
> > > /usr/local/include directory.
> > >
> > > The diff below, tested with sysutils/ggrep, implements approach #2.
> > > If a gnu.port.mk port really wants libstdthreads, one needs to add
> > > devel/libstdthreads to BUILD_DEPENDS (even though it really belongs in
> > > LIB_DEPENDS), or add an override in CONFIGURE_ENV.
> > > The diff isn't complete: it lacks at least REVISION bumps for at least
> > > octave, pspp and link-grammar, and possibly safety bumps for all other
> > > affected ports; but it shows the intent.
> > >
> > > Approach #3 seems to work too but is slightly tricker. wayland/foot
> > > would need a meson.build patch.
> > >
> > > Thoughts?
> >
> > I vote for #1.
> > This is something we should have.

Probably, but "when" and "how" also matter.

As also stressed by sthen, adding it blindly as a build dep to all
those ports may uncover even more unregistered deps.

Also, it brings *no value* to the ports using gnulib: they're already
using pthread-based threading and locking implementations. And
detecting threads.h brings some #ifdef maze using weak symbols. The
implementation in libstdthreads.so isn't even used.

> > #3 is horrible, we already struggle with such constructs in ports and honestly
> > it's a pain

I agree that #3 is a pain and not desirable. I looked less ugly to me
than #1, though...

> > (aka, this should be a short term solution that always ends up for
> > eternity).
> >
> > Matthieu, should this be implemented / moved into base at some
> > point?
>
> Yes that's what I've been saying since c2k23 in Tallinn. The consensus
> was to first add it in ports and wait.
>
> Ihmo if it causes too much trouble for the release just un-hook it
> again (with UNLINKED = wayland) together with fcft and foot.
>
> No one will miss those ports. and we can work on this later again.

Let's call that approach #4. Current ranking of the options here
would be #4, #2, #1 and #3 from most to least desirable. Option #4
has the advantage to leave us with a clean slate after release.

Antoine, would you object to just going back to the status quo ante?

> One difficulty to add it in base it that it doesn't build with
> base-gcc as is.

There are workarounds for that, the easiest is to just build it with
clang where available. But then there are other questions, like,
should it be a standalone lib or should it be integrated to libc, etc.

--
jca