+++ Ben Longbons [2014-12-18 12:23 -0800]:
On Thu, Dec 18, 2014 at 8:36 AM, Wookey woo...@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
