[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#776010: dpkg-cross: Can generate broken binaries due to off_t vs LFS disconnect

+++ Guillem Jover [2015-01-22 18:22 +0100] wrote:

[moving to debian-cross which I think is now the best list for this stuff]

> Some of the config.site files define a value for ac_cv_sizeof_off_t,
> but that value is wrong as it depends on whether the package is going
> to be built with LFS enabled (through AC_SYS_LARGEFILE for example).
> Unfortunately this is unfixable through a config.site deployment as the
> LFS checks are performed way later than when the config cache files have
> been loaded, so the value cannot be assigned depending on LFS.
> Those values would need to be removed from the config.site files, and
> packages that lack the value during cross-compilation would need to be
> updated to use a more recent autoconf which is able to compute such
> sizeof values even when cross-compiling.

OK. that's easy enough to do. It tends to occur twice. Once unconditionally, and once in:
	# parted
	if [ "$PACKAGE" = "parted" -o "$PACKAGE_NAME" = "GNU parted" ]; then

Does parted know if it is being compiled with LFS or not? I presume
not, as LFS is a kernel feature, right(?), which may or may not be enabled.

I was just wondering if there was any justification for leaving this
in. I presume it's just as wrong in this per-package conditional, as
it is 'bare'?

There are a lot of values in dpkg-cross site.config that _could_ be
wrong. The setting are set are set for 'debian, with this glibc and
standard kernel'. Is that in fact a fixed value for LFS? (which would
be a possible excuse for leaving it in).

But we shouldn't be keeping any values which can in fact be determined
at build time, even when crossing, successfully. And it seem that
AC_SYS_LARGEFILE suplies this now.

And indeed current parted does use AC_SYS_LARGEFILE to set this so the
above stanza is no longer needed.

I've fixed all that. Every other variable in this package could do
with similar review...

> Even though I know dpkg-cross is considered completely deprecated and
> that it should be left to die, the config.site support is something
> that is supposed to move elsewhere AFAIK, so that's the reason I've
> bothered reporting this at all.

Yes, some functionality something like this needs to live
somewhere. The design is still up for grabs.

For now dpkg-cross is all we have.

Principal hats:  Linaro, Debian, Wookware, ARM

Reply to: