[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Multilibbed cross-compilers

I have added multilib support to cross-gcc (from cross-gcc_25), and
enabled it as the default.

So the existing cross-gcc-*-* builds in the archive (and the emdebian
test repo) are all using this. Feedback on whether things actually
work as expected would be welcome.

It is enabled.disabled by setting DEB_CROSS_MULTILIB=yes/no
(defaulting to yes if not mentioned). I've exposed that setting in the
debian/rules in the generated cross-gcc-<ver>-<arch> source package so
that it is relatively simple to change in a local build.

The set of multilibs currently generated is as follows:

Debian arch          extra multilib ABIs
amd64               i386 x32
i386                amd64 x32
mips                mips64 mipsn32
mipsel              mips64 mipsn32
powerpc             ppc64
arm64               -
armel               -
armhf               -
ppc64el             -

That's what I inferred matched what gcc native does by peering at a
lot of runes but I could easily be wrong. Is that in fact the set we

The builds currently in the archive are still
wdotap/multiarch-build-deps built, but this support should translate
almost trivially to standalone -cross packages. 

Note that DEB_CROSS_MULTILIB=no (equivalent to DEB_CROSS_NO_BIARCH=yes
and NOLANG=biarch in gcc) requires gcc patches carried in cross-gcc,
because this is no longer supported in gcc itself. At some point we
may decide that single-abi builds are no longer worth maintaining and
drop these, or (better) get support back into gcc. These patches make
cross-gcc somewhat specific to corresponding upstream gcc-source

I know exposing a new variable is arguably confusing, but it's so much
more obvious what DEB_CROSS_MULTILIB does that I thought it made sense
here from a user POV, and there were 2 corresponding knobs in gcc to
twiddle so it makes sense programatically too.

Limited testing so far found that installation deps all work OK and
multilib cross-builds (e.g. zlib, expat) work OK for the build, but
shlibdeps breaks (with expat, after appying #775942):
possibly due to #772184. Which is awaiting a dpkg 1.18 upload to test. 
Confirmation from someone who understands multilib-world would be
welcome. Or indeed any other tests showing that this stuff
does/doesn't actually work.

Principal hats:  Linaro, Debian, Wookware, ARM

Reply to: