Helmut, thank you very much for taking the time to explain. This was all
very valuable context.
On Fri, Jan 31, 2025 at 10:47:23AM +0100, Helmut Grohne wrote:
I considered pushing the results into debian/rules, but was
unconvinced that it would be reasonable to ask maintainers to spend
effort on maintaining these results. If you are happy to do so, sure, go
ahead.
It's worthwhile for me personally, if I can have successful cross builds
in salsa-ci and crossqa.debian.net without too much effort. Salsa-ci in
particular would help me catch these FTCBFS issues before uploading.
ifneq ($(filter cross,$(DEB_BUILD_PROFILES)),)
ifeq ($(DEB_HOST_ARCH_OS)-$(DEB_HOST_ARCH_LIBC),linux-gnu)
CONFIG += --with-yielding-select=yes
endif
ifeq ($(DEB_HOST_ARCH_LIBC),gnu)
CONFIG += ac_cv_func_memcmp_working
endif
endif
So I rabbit-holed on this a bit, and concluded that for these specific
checks in this specific package, I think it's better without the added
conditions.
For ac_cv_func_memcmp_working, its documentation says: "This macro is
obsolescent, as current systems have a working memcmp. New programs need
not use this macro." Also, OpenLDAP actually FTBFS if the answer is no:
https://bugs.openldap.org/show_bug.cgi?id=9228 (WONTFIX). Therefore, for
any system where OpenLDAP can be built natively, the answer must be yes.
ol_cv_pthread_select_yields is kind of fascinating (to me): it's about
early, pure userspace threading implementations, where blocking syscalls
would block the entire process: https://danluu.com/threads-faq/#Q164.
But as far as I can tell, thread-blocking is required by POSIX since
(AFAICT) POSIX.1c-1995 and process-blocking is historic.
For both of these checks, my evaluation is that they are extremely
unlikely to answer "no" on any current or future system; and that
requiring future ports to opt-in is far more likely to just add friction
than to truly detect a broken system.
