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
