Control: reassign -1 cross-config
Control: tags -1 - patch
Control: affects -1 + src:libdmx src:libfs src:libx11 src:libxext src:libxi
src:libxinerama src:libxrandr src:libxrender src:libxres src:libxss src:libxt
src:libxv src:libxvmc src:libxxf86vm
Control: user [email protected]
Control: usertags -1 + ftcbfs
On Mon, Apr 24, 2017 at 06:29:52PM +0700, Do Thanh Trung wrote:
> libxinerama fails when cross-compile with dpkg-buildpackage:
> $ CONFIG_SITE=/etc/dpkg-cross/cross-config.armhf DEB_BUILD_OPTIONS=nocheck
> dpkg-buildpackage -aarmhf
>
> By default, in configure, "malloc0returnsnull" is "auto" and it requires
> compile and run a test code
> which cannot execute when cross build.
> Error:
> | checking whether malloc(0) returns NULL... configure: error: in
> `libxinerama-1.1.3/build':
> | configure: error: cannot run test program while cross compiling
>
>
> The cross-compile could pass if option "malloc0returnsnull" is specified
> ("enable" or "disable").
Yes. An alternative is exporting the environment variable
xorg_cv_malloc0_returns_null with a suitable value.
> I think we could add this option to debian/rules. I've attached a patch for
> this.
> In the patch, option "--disable-malloc0returnsnull" is default,
> but option "--enable-malloc0returnsnull" will be called if
> param "malloc0returnsnull" is passed to DEB_BUILD_OPTIONS.
I think this approach is bad for multiple reasons. For one thing you
list a pile of packages that need to be patched. Centralizing this
change into one package would be much better to reduce the maintenance
cost.
Seeding the value via DEB_BUILD_OPTIONS does not really buy us anything
as we can quite simply set xorg_cv_malloc0_returns_null already.
Picking a default may be bad as the check result is dependent on the
libc implementation. At present, Debian only has one supported libc
(which happens to be glibc), but various people attempted using musl and
uclibc already.
The centralization aspect can be resolved by fixing it in cross-config.
The config/cross-config.cache already sets
ac_cv_func_malloc_0_nonnull=yes, so adding
xorg_cv_malloc0_returns_null=no there shouldn't hurt anything that works
at present. It should be conditionalized for glibc however.
In the mean time, exporting the variable is a reasonable workaround.
Helmut
