Bug#1094386: openldap FTCBFS: uses the build architecture compiler

[Ryan Tandy]

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.