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