Bug#771070: requirements for cross toolchain packages in the distribution
+++ Ben Longbons [2014-12-18 12:23 -0800]:
> 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.
Indeed. This seems like a bad thing, but in fairness, emdebian and
ubuntu have been shipping cross-compilers where the versions do not
necessarily match for quite some time, and it hasn't caused obvious
practical problems.
So maybe this doesn't matter, but I'd really like to understand
exactly what's going on so we could see what might break, and thus
allocate an importance.
In practice I presume that all these libraries are dynamically linked
so in fact what matters is what versions are available at runtime, and
how tight the dependencies are.
> 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.
In general, even if the compiler is built against libc-$arch-cross,
(and thus it is installed along with the toolchain) programs built
with that compiler should link against libc:$arch. I have seen cases
where they don't, and end up linking against the libc-$arch-cross copy
instead. I don't have a good handle on how common this is.
But clearly, if there isn't a libc-$arch-cross 'internal' copy present
then this problem can't arise. On the other hand, having the two
'flavours' of libc lets you install the toolchain 'within-arch', and
avoids uninstallability-due-to-multiarch-skew in unstable.
> > 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.
This is the relevant page:
https://wiki.debian.org/CoinstallableToolchains
which has links to the bug at the bottom:666743. Helmut has the best
handle on the changes needed for this, and so far as I know Doko did
not object to the moving around of symlinks which makes this possible
(it was discussed at the bootstrap sprint
https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results section 3.11).
Up to date patches would be good, to get this moving.
> 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).
Yeah that's all a pain. Blame the x86 people for using 3 different
triplets for the same ABI.
> > 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.
Right. This is the logical outcome of using multiarch for library
dependencies. If you don't do this you have treat supported and
unsupported arches differently.
> 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) ...
Bootstrapping involves generating an archive of the newly-built arch,
yes. Not sure if that's what you meant exactly.
> 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.
I assume you mean {/usr,}/lib/$arch (I.e multiarch paths)? {/usr,}/$arch/lib
is the 'classic crosscompiling' paths
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: