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.
No comments:
Post a Comment