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

[Helmut Grohne]

Hi Ryan,

On Thu, Jan 30, 2025 at 05:28:28PM -0800, Ryan Tandy wrote:
> I have a more general question: are configure flags or cache variables for
> bypassing native checks stored somewhere central? For openldap, I'm talking

This is a long-standing question and the answer is complicated and
non-satisfactory. I am expecting that this is of general interest and
thus Ccing d-cross.

There is cross-config from dpkg-cross. It predates my involvement and it
is the oldest approach to the problem. It provides a central config.site
file and sbuild (but not pbuilder) loads it by default. It quite
unmaintained and wrong in quite a number of ways. I even acquired the
rune

    --chroot-setup-commands=install -D /dev/null /etc/dpkg-cross/cross-config.%SBUILD_HOST_ARCH

to opt out of it.

The central nature is not purely an advantage. The properties being
recorded are not recorded with the packages the properties reason about.
You give ac_cv_func_memcmp_working as an example and it is examining a
function of libc6-dev, so arguably, libc6-dev should install the answer,
right? I tried drafting this by writing a config.site file that would
include /usr/lib/${DEB_HOST_MULTIARCH}/config.site/*, but this is not
useful as a Debian-ism as it would have to be carried upstream to be
maintained well. Unfortunately, I never encountered any Yocto, Buildroot
or PtxDist people that found this mechanism useful and therefore I
dropped it.

> about ol_cv_pthread_select_yields (--with-yielding-select) and
> ac_cv_func_memcmp_working. I assume you must be setting these for your cross
> builds. Do you have a repository of such workarounds in a git repository, or
> a package, or such?

There are two more angles of interest here. One angles is generality.
While ac_cv_func_memcmp_working is fairly general and used by around
five packages including openldap, ol_cv_pthread_select_yields has no
users outside openldap. I argue that ol_cv_pthread_select_yields is more
specific to openldap than to glibc and thus it would likely be better to
be maintained there.

The other is the buildsystem. The config.site mechanism is highly
specific to GNU autotools, but autotools are significantly declining in
popularity. CMake and Meson have similar (but incompatible) mechanisms
and similar popularity. As a result, the practical benefit from
centralizing these variables has significantly decreased over time.

When I look at failing configure due to cache variables, I also
encountered a *lot* of checks that would work without running host code.
Often times (but the ones you mention), using AC_LINK_IFELSE or
AC_COMPUTE_INT would be good enough.

As a result, I see the benefits from centralizing these cache variables
as diminishing in returns and have tried eliminating their need where
possible and left the problem to the builder (as you observed with
openldap). 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.

> Does it make sense to consolidate those workarounds in the package itself?
> For example:
> 
> +ifneq ($(filter cross,$(DEB_BUILD_PROFILES)),)
> +       CONFIG += --with-yielding-select=yes ac_cv_func_memcmp_working=yes
> +endif
> 
> Would that be a good change?

Generally, the cross profile is used to indicate that you cannot run
host code. As a result its use here is spot on. Then, there would not be
a need for these checks if the answer was universally yes, right? I'd be
slightly more cautious and restrict the passing of the flags to
known-good situations.

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

It is slightly more complex, but it causes stuff to fail loudly when
doing strange ports.

There is one more step that you may go to gain extra assurance. Consider
checking the results in native passes.

ifeq ($(DEB_HOST_ARCH_OS)-$(DEB_HOST_ARCH_LIBC),linux-gnu)
  CROSS_CONFIG += ol_cv_pthread_select_yields=yes
endif
ifeq ($(DEB_HOST_ARCH_LIBC),gnu)
  CROSS_CONFIG += ac_cv_func_memcmp_working=yes
endif
ifeq ($(filter cross,$(DEB_BUILD_PROFILES)),)
  # Verify that the configure script actually produced the cache
  # variables with the values from CROSS_CONFIG
else
  CONFIG += $(CROSS_CONFIG)
endif

This likely is not the answer you were looking for, but I hope it helps
somewhat. Cross building is a huge space of problems and there is only
so much time to solve some of them. This is one of those, that I
actively deprioritized as I saw other areas in more urgent need of
effort.

Should we add this matter for wider discussion to
https://wiki.debian.org/Sprints/2025/BootstrapCrossbuild?

Helmut