Re: libstdthreads threads.h detection and gnulib

On Sun, Sep 15, 2024 at 10:49:13AM +0100, Stuart Henderson wrote:
> On 2024/09/14 08:12, Antoine Jacoutot wrote:
> > On Fri, Sep 13, 2024 at 05:48:16PM +0200, Jeremie Courreges-Anglas wrote:
> > > On Fri, Sep 13, 2024 at 08:50:00AM +0200, Antoine Jacoutot wrote:
> > > > On Thu, Sep 12, 2024 at 06:38:17PM +0200, Jeremie Courreges-Anglas wrote:
> > > > > 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
>
> Agreed.
>
> > > > > > > > 2. "poison" threads.h detection for gnu.port.mk ports. This should be
> > > > > > > > enough for the gnulib occurences.
>
> I think this is a good approach for now. Obviously won't help any cmake
> or meson ports but the problems we know about so far are in autoconf.
>
> > > > > > > > 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.
>
> I'd prefer not.
>
> > > > > > > I vote for #1.
> > > > > > > This is something we should have.
> > > > >
> > > > > Probably, but "when" and "how" also matter.
>
> #1 with stdthreads in ports will give us something like the problem
> we had with the backtrace functions.
>
> My feeling is that having this in base would make the most sense.
> probably in libpthread if using those functions as the backend. (libc
> would be lower friction - these functions are in glibc on linux - but
> libpthread wouldn't be too hard to work with and they're there in at
> least one other implementation. There doesn't seem any benefit to
> using a whole new library).
>
> > > > It would mean downgrading textproc/link-grammar and fixing
> > > > multimedia/pipewire/pipewire as well as going back to the previous state for the
> > > > ports that matthieu mentioned.
> > > >
> > > > Would poisonning threads.h be enough for gnu ports and we can leave pipewire and
> > > > link-grammar as-is?
> > >
> > > I hope the answer is "yes". That was the idea behind my initial
> > > proposal. The result of the poisoning:
> > >
> > > checking for threads.h... (cached) no
> > >
> > > ok?
> > >
> > >
> > > Index: infrastructure/db/config.no-stdthreads
> > > ===================================================================
> > > RCS file: infrastructure/db/config.no-stdthreads
> > > diff -N infrastructure/db/config.no-stdthreads
> > > --- /dev/null 1 Jan 1970 00:00:00 -0000
> > > +++ infrastructure/db/config.no-stdthreads 13 Sep 2024 13:42:26 -0000
> > > @@ -0,0 +1,3 @@
> > > +# $OpenBSD$
> > > +# included unless devel/libstdthreads
> > > +ac_cv_header_threads_h=${ac_cv_header_threads_h=no}
> > > Index: infrastructure/mk/gnu.port.mk
> > > ===================================================================
> > > RCS file: /home/cvs/ports/infrastructure/mk/gnu.port.mk,v
> > > diff -u -p -r1.61 gnu.port.mk
> > > --- infrastructure/mk/gnu.port.mk 14 May 2019 14:59:56 -0000 1.61
> > > +++ infrastructure/mk/gnu.port.mk 13 Sep 2024 13:42:26 -0000
> > > @@ -43,7 +43,8 @@ CONFIG_SITE_LIST += config.site
> > > textproc/gsed gsed \
> > > archivers/gtar* gtar \
> > > lang/gawk gawk \
> > > - sysutils/coreutils coreutils
> > > + sysutils/coreutils coreutils \
> > > + devel/libstdthreads stdthreads
> > > . if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:M$d}
> > > CONFIG_SITE_LIST += config.no-${name}
> > > . endif
> >
> > Nice!
> > I wasn't aware this was doable like this.
> >
> > OK for me but I am just discovering this feature :-)
>
> OK. I think this is the best short-term fix.
>

Ok by me too, fwiw.
--
Matthieu Herrb