When using a build.rs script to dynamically generate bindgen bindings
at build-time, it will run on the host, and by default bindgen will
generate bindings for the host arch/libc instead of the target.
To generate the bindings on cross, we need to use BINDGEN_EXTRA_CLANG_ARGS
to specify the proper sysroot and include path for the target.
These arguments are not used for anything other than bindgen's clang
invocation.
As of it's now, package built with build-helper/qmake natively won't
pick our CFLAGS CXXFLAGS and LDFLAGS. The result could be seen in no
debug symbol in djview.
Furthermore, cross build won't pick our hardening flags.
Let's force qmake pick our flags by using the same method as
build-style/qmake.
At least KiCAD tries to find wx-config-gtk3 in the current directory,
without looking for it in PATH, so the build fails. Actually give it a
full path, like we do for the cross build case.
The cc-rs crate will try to guess the host compiler and use default
flags these are not specifically set. The default behavior is wrong in
Void cross-compilation environments. Explicitly define HOST_CC=gcc and
use innocuous HOST_CFLAGS=-O2 just to thwart the bad defaults.
Co-authored-by: Érico Rolim <erico.erc@gmail.com>
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
Closes: #28416.
Packages that link against python3-numpy require special consideration
to ensure that, in a cross-building environment, target libraries and
headers as well as the FORTRAN compiler and linker are properly
identifeid. Previously, this was done directly in the python3-scipy
template to support cross compilation. Now, a build_helper generalizes
these changes to support other package templates.
When cross building a package using build_helper="gir" add the
gtk+3-devel package to the hostmakedepends in case it is
contained in the makedepends.
Remove the specific case in gcr now that this is automatic.
