Bug#868483: cross-config: cross-config files missing for multiple architectures
On Sat, 25 May 2019 07:21:19 +0200 Helmut Grohne
wrote:
> Control: severity -1 serious
>
> On Sat, May 25, 2019 at 02:13:39AM +0100, Wookey wrote:
> > > I think this should be fixed asap, ideally in buster. Do you
> > > agree with bumping this bug to rcness?
> >
> > Yes
>
> Bumped.
>
> > > Do you also agree with removing all ac_cv_sizeof_*? (At a later
> > > time)
> >
> > If they are no longer needed by builds, yes. Do packages actually
> > get these from the compiler now or does something else populate
> > these variables when crossing?
>
> "Recent" autotools gained an AC_COMPUTE_INT to determine the value of
> a compile time integral expression. During native compilation it is
> essentially printf("%d", ...). For cross compilation autotools
> implements it using bisection on char "somearray[integral_expression <
> test_value ? 1 : -1];". Repeatedly compiling such programs allows
> deducing the value as negatively sized arrays yield a compilation
> failure. AC_CHECK_SIZEOF is not implemented using AC_COMPUTE_INT.
>
> Very old configure scripts may still need ac_cv_sizeof_*. The last
> one I knew was blt #772590. I don't think we have an old-enough
> autoconf in the archive, so any package that fails now is missing
> source.
>
> For these reasons, I think that continuing to maintain ac_cv_sizeof_*
> is not reasonable. And if we do so, we should generate them using
> AC_CHECK_SIZEOF at build time. Or just remove them.
I think it's definitely reasonable to retain ac_cv_sizeof_* for buster.
The list can be optimised and improved for bullseye.
I've prepared a package based on the debdiff from the previous reply
and I'll upload today.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp56i43zLFrC.pgp
Description: OpenPGP digital signature
Bug#868483: cross-config: cross-config files missing for multiple architectures
Control: severity -1 serious
On Sat, May 25, 2019 at 02:13:39AM +0100, Wookey wrote:
> > I think this should be fixed asap, ideally in buster. Do you agree with
> > bumping this bug to rcness?
>
> Yes
Bumped.
> > Do you also agree with removing all ac_cv_sizeof_*? (At a later time)
>
> If they are no longer needed by builds, yes. Do packages actually get
> these from the compiler now or does something else populate these
> variables when crossing?
"Recent" autotools gained an AC_COMPUTE_INT to determine the value of a
compile time integral expression. During native compilation it is
essentially printf("%d", ...). For cross compilation autotools
implements it using bisection on char "somearray[integral_expression <
test_value ? 1 : -1];". Repeatedly compiling such programs allows
deducing the value as negatively sized arrays yield a compilation
failure. AC_CHECK_SIZEOF is not implemented using AC_COMPUTE_INT.
Very old configure scripts may still need ac_cv_sizeof_*. The last one I
knew was blt #772590. I don't think we have an old-enough autoconf in
the archive, so any package that fails now is missing source.
For these reasons, I think that continuing to maintain ac_cv_sizeof_* is
not reasonable. And if we do so, we should generate them using
AC_CHECK_SIZEOF at build time. Or just remove them.
Helmut
Bug#868483: cross-config: cross-config files missing for multiple architectures
Control: severity -1 important Control: tags -1 + patch On Mon, Jul 24, 2017 at 05:07:28PM +0100, Wookey wrote: > On 2017-07-16 00:01 +0200, John Paul Adrian Glaubitz wrote: > > Either way, the list should be consistent or removed altogether. Agreed. > We have not tried to provide files for arches where we are not sure of > the answers. The idea was that porters would provide info for their > architectures, and thus get the details right. We could probably find > out the answers for various arches with some effort. If you provide > files I am happy to include them. I guess I could check by logging on > to porter boxes and collecting suitable details. There are a number of arch-specific cache variables, but also a number that depend on kernel/libc. Given that all release archs are Linux/glibc, the latter ones have been collected in config/cross-config.cache despite being wrong for hurd-any, kfreebsd-any and musl-linux-any. I've set up crossqa.debian.net to deviate as little as possible from the standard developer workflow (using sbuild) and that means using dpkg-cross. Consequently, a lot (around 200) of packages FTCBFS for mips64el, ppc64el and s390x, because they lack ac_cv_func_malloc_0_nonnull=yes (which sits in the general cross-config.cache). Failures due to really arch-specific values are rare. The arch-specific sizeof caches are generally useless, because any remotely recent autoconf doesn't need them any longer. We even fixed blt to stop using them. At present I don't know a single package using them. Therefore I suggest the following route: For each "relevant" architecture (at least all release architectures), create a config/cross-config.$ARCH containing at least: . `dirname $ac_site_file`/cross-config.cache For all existing per-arch cache files, ensure that this line is present (e.g. amd64 misses it). Doing just this solves a large fraction of the practical issues. The attached patch shows how simply the change is. Do you agree with the change? Do you agree that it largely (but not entirely) solves the reported bug? I think this should be fixed asap, ideally in buster. Do you agree with bumping this bug to rcness? Do you also agree with removing all ac_cv_sizeof_*? (At a later time) Helmut diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.alpha dpkg-cross-2.6.15/config/cross-config.alpha --- dpkg-cross-2.6.15/config/cross-config.alpha 2015-01-22 20:16:37.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.alpha 2019-04-06 07:18:42.0 +0200 @@ -1,3 +1,4 @@ +. `dirname $ac_site_file`/cross-config.cache # # alpha specific configure variables # diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.amd64 dpkg-cross-2.6.15/config/cross-config.amd64 --- dpkg-cross-2.6.15/config/cross-config.amd64 2011-03-27 08:14:10.0 +0200 +++ dpkg-cross-2.6.15/config/cross-config.amd64 2019-04-06 07:18:27.0 +0200 @@ -1,3 +1,4 @@ +. `dirname $ac_site_file`/cross-config.cache # # amd64-specific configuration variables # diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.hppa dpkg-cross-2.6.15/config/cross-config.hppa --- dpkg-cross-2.6.15/config/cross-config.hppa 2011-03-27 08:14:10.0 +0200 +++ dpkg-cross-2.6.15/config/cross-config.hppa 2019-04-06 07:19:17.0 +0200 @@ -1,3 +1,4 @@ +. `dirname $ac_site_file`/cross-config.cache # # hppa specific configure variables # diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.m68k dpkg-cross-2.6.15/config/cross-config.m68k --- dpkg-cross-2.6.15/config/cross-config.m68k 2011-03-27 08:14:10.0 +0200 +++ dpkg-cross-2.6.15/config/cross-config.m68k 2019-04-06 07:18:48.0 +0200 @@ -1,3 +1,4 @@ +. `dirname $ac_site_file`/cross-config.cache # # m68k specific configure variables # diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.mips64el dpkg-cross-2.6.15/config/cross-config.mips64el --- dpkg-cross-2.6.15/config/cross-config.mips64el 1970-01-01 01:00:00.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.mips64el 2019-04-06 07:21:27.0 +0200 @@ -0,0 +1 @@ +. `dirname $ac_site_file`/cross-config.cache diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.ppc64el dpkg-cross-2.6.15/config/cross-config.ppc64el --- dpkg-cross-2.6.15/config/cross-config.ppc64el 1970-01-01 01:00:00.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.ppc64el 2019-04-06 07:19:31.0 +0200 @@ -0,0 +1 @@ +. `dirname $ac_site_file`/cross-config.cache diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.s390x dpkg-cross-2.6.15/config/cross-config.s390x --- dpkg-cross-2.6.15/config/cross-config.s390x 1970-01-01 01:00:00.0 +0100 +++ dpkg-cross-2.6.15/config/cross-config.s390x 2019-04-06 07:19:27.0 +0200 @@ -0,0 +1 @@ +. `dirname $ac_site_file`/cross-config.cache diff --minimal -Nru dpkg-cross-2.6.15/debian/changelog dpkg-cross-2.6.15/debian/changelog --- dpkg-cross-2.6.15/debian/changelog 2017-07-24
Bug#868483: cross-config: cross-config files missing for multiple architectures
On 2017-07-16 00:01 +0200, John Paul Adrian Glaubitz wrote: > While working on fixing some issues with cross-building native > versions of gcc, I noticed that dpkg-cross is missing the > cross-config files for multiple architectures: > > * mips64el > * powerpcspe > * ppc64 > * ppc64el > * s390x > * sparc > * sparc64 > * x32 > > I'm not sure whether these configuration files are actually still > being used since at least for gcc they are actually creating problems > when cross-building from 64 to 32 bits, but that's most likely due to > a flawky configure script in gcc. Ideally these things would all be discovered at build-time correctly, but so fart as I know these values are still used by configure for at least some packages. Providing them remains useful for the time being. > I'm also not sure about hurd-i386, > kfreebsd-i386 and kfreebsd-amd64 as I never cross-built for these > targets. Me neither. > Either way, the list should be consistent or removed altogether. We have not tried to provide files for arches where we are not sure of the answers. The idea was that porters would provide info for their architectures, and thus get the details right. We could probably find out the answers for various arches with some effort. If you provide files I am happy to include them. I guess I could check by logging on to porter boxes and collecting suitable details. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#868483: cross-config: cross-config files missing for multiple architectures
Source: dpkg-cross Version: 2.6.15-1 Severity: normal User: helm...@debian.org Usertags: rebootstrap Hi! While working on fixing some issues with cross-building native versions of gcc, I noticed that dpkg-cross is missing the cross-config files for multiple architectures: * mips64el * powerpcspe * ppc64 * ppc64el * s390x * sparc * sparc64 * x32 I'm not sure whether these configuration files are actually still being used since at least for gcc they are actually creating problems when cross-building from 64 to 32 bits, but that's most likely due to a flawky configure script in gcc. I'm also not sure about hurd-i386, kfreebsd-i386 and kfreebsd-amd64 as I never cross-built for these targets. Either way, the list should be consistent or removed altogether. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
