Thanks for all your work on core toolchains!


Unfortunately, ever since February 4th, which seems to roughly
coincide with the 12.2 upload of build-essential to unstable, I've
been getting errors when trying to cross-build u-boot:

  dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by debian/u-boot-tools/usr/bin/mksunxiboot (ELF format:
                  'elf32-littlearm'; RPATH: '')

Using sbuild's "--add-depends libc6-dev:armhf" does work around the
issue for me, but it seems a bit cumbersome to manually specify
cross-build dependencies...


According to the changelog, libc6-dev apparently was dropped
intentionally:

  build-essential (12.2) unstable; urgency=medium

    * Bump dependencies on gcc and g++ to 5.3.
    * For cross packages, drop libc-dev dependency on libc-dev.

Hi,

Speaking with my sbuild maintainer hat on, I was made aware of this bug through
a request to add libc-dev:$hostarch and libstdc++6-dev:$hostarch as additional
implicit crossbuild dependencies to sbuild in addition to the existing
crossbuild-essential-$hostarch crossbuild dependency. This would remove the
need to manually add "--add-depends libc6-dev:$hostarch" to the sbuild
invocation when cross building for $hostarch with the new crossbuild-essential
packages as described by vagrant.

I would assume that packages should be able to rely on libc-dev:$hostarch being
installed as part of build-essential no matter whether the host architecture
equals the build architecture or not. Since I wonder where the right place is
to fix this problem is and whether I should really modify sbuild, I'd like to
join vagrant in their plea to get to know why this change was made in the 12.2
upload of src:build-essential.

Intuitively it feels wrong to carry more implicit dependencies like
build-essential and crossbuild-essential-$arch than necessary in packages
resolving or checking crossbuild dependencies like sbuild, pbuilder,
mk-build-deps, dose3, dpkg-checkbuilddeps or `apt-get build-dep`. Naively, I
thought that the point of the crossbuild-essential-$arch packages was to encode
the essential multiarch crossbuild dependencies in a single binary package
rather than hardcoding them in multiple pieces of dependency resolving software
which makes these architecture specific lists hard to maintain or keeping them
in sync.

So how and where should this best be handled?

Thanks!

cheers, josch

having a dependency on a foreign arch prevents migration to testing, so for now
I prefer having packages in testing. of course a recommends could be added.

I just hit this too. This issue makes crossbuild-essential-arch useless.

doko: is the concern in your note on this bug report still valid? If so,
what specifically prevents this migration to testing? Is there some tool
in the infrastructure that's not sufficiently Multi-Arch aware? Which
tool is it?

Since stretch is now frozen, can we please fix this in sid now, and
agree to prioritize fixing whatever is still broken in the tooling? I
can work on it if you point out the culprit.

I hit this again when cross-compiling z3 to riscv64 over at #948109. Even worse, there you need all of

please create a few test packages in the archive to test how the current Debian
infrastructure handles foreign architectures:

 - a source package not b-d on a foreign architecture,
   creating a binary package depending on one foreign
   architecture.
   The foreign architecture is a release architecture.

 - a source package not b-d on a foreign architecture,
   creating a binary package depending on more than one
   foreign architecture.
   The foreign architecture is a release architecture.

 - a source package not b-d on a foreign architecture,
   creating a binary package depending on one foreign
   architecture.
   The foreign architecture is a ports architecture.

 - a source package not b-d on a foreign architecture,
   creating a binary package depending on more than one
   foreign architecture.
   The foreign architecture is a ports architecture.


 - a source package b-d on a a foreign architecture,
   creating a binary package depending on one foreign
   architecture.
   The foreign architecture is a release architecture.

 - a source package b-d on a a foreign architecture,
   creating a binary package depending on one foreign
   architecture.
   The foreign architecture is a ports architecture.