Bug#771070: requirements for cross toolchain packages in the distribution
On Thu, Dec 18, 2014 at 8:36 AM, Wookey <wookey@wookware.org> wrote:
> MA-built vs in-arch
> -------------------
> I guess an interesting question is 'what does the cross-compiler
> actually _use_ the foreign arch libc for'? Does it need its own
> independent copy? What happens when the compiler libc-$arch-cross and
> the system libc:$arch get out of sync. Does it matter?
The thought of this gives me nightmares. Glibc is very good at
backwards-compatibility as far as packages go, but does not even
attempt forwards-compatibility.
If anything (I'm still confused if this means only libstdc++, or every
user program - but for those of us writing C++ I suppose it makes no
difference) gets built against libc-$arch-cross (= 2.999) but at
runtime there is only libc:$arch (= 2.998), then programs will almost
certainly fail to load because of missing symbol versions, and
possibly even fail to link.
> multilib vs mulitarch
> ---------------------
> Native compilers are not yet co-installable so have to use multilib to
> target more than one ABI.
Can we please fix this? I'm tired of having to special-case my
buildbot scripts for arches only available through multilib (i586 and
gnux32 on an amd64 host; this also prevents ever running my buildbot
on anything other than amd64). For all other arches (native or
multiarch cross) the script is trivial.
It does not work to just make my own ~/bin/i586-linux-gnu-gcc etc
scripts that call x86_64-linux-gnu-gcc -m32, because I also have to
worry about the libs being in the wrong place ({/usr,}/lib32 instead
of {/usr,}/lib/i586-linux-gnu, except that it's really
{/usr,}/lib/i386-linux-gnu ... why can't the numbers be consistent?
It's even i486-linux-gnu in places too ... meh, unimportant to this
discussion, except I suppose I'll need to special-case the library
locations anyway, or else lie any call my binaries packages i386 even
though they're really i586 ... it's not like everyone else doesn't
anyway).
> Multilibs do make much better sense for arches that are not in the
> archive (x32/mipsn32) and are possibly the easier way to support
> those, but even there, all the difficulty is in getting the right
> libc:$arch or libc-$arch-cross packages. Once you have those you can
> build per-arch toolchains or multilib toolchains.
The most correct solution to me seems to be a "libs only" archive even
for unsupported arches. This would be a huge win even for supported
arches, because 'apt-get update' with N architectures enabled is
really slow already.
Conceptually it would be split into 3 areas that I can think of:
1. anything that ships architecture-specific binaries (not usable in
cross situations in general, but there are still useful packages like
wine32)
2. anything that ships architecture-specific libraries but not
binaries (useful for cross)
3. anything that ships no architecture-specific binaries or libraries
2 is Multi-Arch: same and 3 is Architecture: all, so we already have
an easy way to identify these sets of packages. That said, I can't
think of any case where 1 or 3 would be *used* on their own - 1 deps
on 2 and 3 is only usable with some 1.
Because of packages like wine32, it's impossible to default to only
shipping 2 for non-native arches, so perhaps there could be a second
repo (e.g. <http://http.debian.net/debian-libsonly> instead of
<http://http.debian.net/debian>) automatically generated from the main
one (at least for supported arches)? I'm sure there's a way to do this
for x32 packages also (I would be surprised if bootstrapping doesn't
do something like this already, but my familiarity with Debian is as a
user) ... for that matter, in the age of supported cross-gcc, I can
imagine running a future-vanilla debian buildbot for an arch that
doesn't exist yet and using that to populate the initial archive.
> There is some upstream expectation of multilib support, which is the
> best argument for enabling it. I don't think debian packages should be
> using it - they should use gcc-triplet thoughout (then they don't care
> how those triplets are packaged-up). We could use a gcc wrapper to
> recignise multilib options call the corresponding triplet-gcc. I
> beleive this was how guillems 'fake cross-toolchains' worked?
That was my thought too, but I think the important part is "backward
compatibility with user build scripts" rather than "upstream
expectation". If we limited ourselves to upstream expectation,
{/usr,}/$arch/lib wouldn't exist, and we all agree that that's a win,
right? And using that as a guideline, it doesn't have to be *perfect*
backward compatibility, there were certainly packages that needed
patching to deal with it.
-Ben
Reply to: