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
> > > > > >
> > > > > > 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?
> >
> > 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 :-)
> Index: math/octave/Makefile
> ===================================================================
> RCS file: /home/cvs/ports/math/octave/Makefile,v
> diff -u -p -r1.142 Makefile
> --- math/octave/Makefile 4 Sep 2024 07:30:39 -0000 1.142
> +++ math/octave/Makefile 13 Sep 2024 13:50:03 -0000
> @@ -2,7 +2,7 @@ COMMENT = Scientific Programming La
>
> VERSION = 7.3.0
> DISTNAME = octave-${VERSION}
> -REVISION = 8
> +REVISION = 9
> EXTRACT_SUFX = .tar.xz
> CATEGORIES = math
>
> @@ -40,7 +40,6 @@ MODULES = fortran \
> x11/qt5
>
> BUILD_DEPENDS = ${MODFORTRAN_BUILD_DEPENDS} \
> - devel/libstdthreads \
> math/gnuplot \
> print/texinfo \
> textproc/gsed
> Index: math/pspp/Makefile
> ===================================================================
> RCS file: /home/cvs/ports/math/pspp/Makefile,v
> diff -u -p -r1.16 Makefile
> --- math/pspp/Makefile 9 Sep 2024 11:25:30 -0000 1.16
> +++ math/pspp/Makefile 13 Sep 2024 13:53:36 -0000
> @@ -1,6 +1,6 @@
> COMMENT = program for statistical analysis of sampled data
> DISTNAME = pspp-1.4.1
> -REVISION = 5
> +REVISION = 6
> CATEGORIES = math x11
>
> HOMEPAGE = https://www.gnu.org/software/pspp/
> @@ -30,7 +30,6 @@ MODULES = lang/python
> MODPY_RUNDEP = No
>
> BUILD_DEPENDS = devel/gettext,-tools \
> - devel/libstdthreads \
> print/texinfo
>
> LIB_DEPENDS = databases/postgresql \
>
>
> --
> jca
>
--
Antoine
No comments:
Post a Comment