Re: cross-toolchain docs
(Drop Jonas CC && add CC to debian-embedded)
Hello,
2009/10/23 Loïc Minier <lool@dooz.org>:
>> Yes, http://www.emdebian.org/~zumbi/docs/deps.pdf
>> This visualization is not perfect, but understandable.
>
> Hmm this sounds like eglibc, gcc, eglibc, gcc, eglic, gcc; if I trust
> EGLIBC.cross-compiling, gcc, eglibc, gcc, eglic, gcc is enough (I have
> a semi working cross compiler built like this).
It is gcc, libc, gcc, libc, gcc, as eglibc document. I had adapt this
howto to be a shell script,
http://www.emdebian.org/~zumbi/docs/EGLIBC.cross-building.sh,
but it does not work for all arches. I assume you are only interested on armel.
>> I have been working towards integrate this framework (part of it
>> should be at emdebian git repo[1]), but I am finding some solutions to
>> the issues I have right now with eglibc and libgcc1 circular
>> dependencies that I could try to explain if you are interested. I
>> tried to find answers from maintainers with no answer from them.
>
> Would love that; I didn't meet circular deps myself yet.
There are a couple of approaches to have toolchains built at Debian's
autobuilders,
1) Cross toolchains being output from native packages, Matthias did
not like to maintian a cross set of tools and this approach means to
bugreport to BTS in order maintainers, mainly Matthias, can apply the
patches.
2) Cross toolchains output from a new source package, build depending
on -source package, in order to avoid source code duplication in the
archive. This is current approach for doing the work.
So far, binutils and linux-libc-dev are no problem, but eglibc-libgcc1
have circular dependencies and again you have several ways to get
through it,
2.1) 3 stage build, not depends on dpkg-cross, but you need to
implement the first bootstrap to gcc cross packages (more or less what
EGLIBC.cross-compiling document tells)
2.2) 2 stage build (what it is currently done), depends on
dpkg-cross, but do not need to implement 1st stage bootstrap for the
xgcc cross compiler
The 2.2 method, uses dpkg-cross (apt-cross) to dowload other
architecture (libs & includes) and dpkg-cross adapts paths, .pc files,
depends naming, ... (this trick leads you to have already compiled
libs & includes in your system, as eglibc libs & includes). So, how do
you implement a package that provide this kind of thing? The answer is
multiarch (still have to find a plan for -dev packages). How do we
workarround it before multiarch? I do not know what ftpmaster will
think of having packages that, 2.2.1) either crossbuilds itself and
then ran dpkg-cross over some packages (libc6,libc6-dev mainly) or
2.2.2) apt-cross a bin-package and dpkg-crosses it to fullfil gcc-X.Y
depends. Once eglibc and other libs and include packages have a way to
build in the autobuilders (see zlib1g, zlib1g-dev, libmpfr, libunwind,
libmudflap, ...) the work is done.
There is some work done to bootstrap a uClibc cross toolchain (Ron Lee
patches on list) and it attempts to remove dpkg-cross dependency from
gcc build[1].
I hope this to be clear, if not, I could try again, let me know. :-)
> However I do have some wonders on three topics:
> * why are cross packages built during e.g. the gcc build not generated
> with dpkg-cross?
dpkg-cross only works for libs & includes and it used to implement -a
option to dpkg-buildpackage so you could trigger cross builds this way
(not sure if this already has merged into dpkg), e.g.
(with a crosstool installed)
$ apt-get source eglibc
$ cd eglibc-2.9
$ dpkg-buildpackage -aarmel -us -uc
What we need from fresh built armel eglibc is to dpkg-cross the needed packages,
$ dpkg-cross -a armel -b libc6_2.10.1-1_armel.deb
$ dpkg-cross -a armel -b libc6-dev_2.10.1-1_armel.deb
$ ls
libc6_2.10.1-1_armel.deb libc6-armel-cross_2.10.1-1_all.deb
libc6-dev_2.10.1-1_armel.deb libc6-dev-armel-cross_2.10.1-1_all.deb
Then install debs.
Alternatively,
$ apt-cross -a armel -S unstable -i libc6
$ apt-cross -a armel -S unstable -i libc6-dev
Then cross toolchain packages have a special built, but for regular
packages Emdebian aims to build them using -a flag.
> * how do we want to do a full cross-toolchain build?
> - What I did first was a special source package which you rename to
> build the various stages; you can see how it looks like in the bzr
> branch lp:~lool/+junk/cross-toolchain or see my PPA for sample
> packages https://launchpad.net/~lool/+archive/ppa
> this is pain because it duplicates file lists and configure args
> handling from gcc
I'll look into this, sometime next week
> - What we could do instead is ship gcc's .dsc, .diff.gz and
> .orig.tar.gz in gcc-source and the same for eglibc etc. and then
> have a package build-deping on all -source and doing dpkg-source -x
> + GCC_TARGET=armel dpkg-buildpackage on all in a sort of meta build
> This is what doko suggested I should do instead of my current
> approach.
For GCC is fine, it needs DEB_CROSS=yes and DEB_CROSS_NO_BIARCH=yes
(due to 504487, introduced by the same time when mips tri-arch was
enabled in Debian's GCC)
For EGLIBC is diferent, either use dpkg-cross over bin-packages or you
cross build it "as is", then apply dpkg-cross or you modify the cross
build config in order to have libs and includes in the right paths.
Check for reference a build script maintained by both, me and Thiemo
Seufer, for reference on how we do stuff
http://www.emdebian.org/repos/current/emdebian/trunk/buildcross/trunk/buildcross-ths
I currently use buildcross, but code needs a major cleanup, which I
have not done in years. It is explained under Debian wiki pages [2][3]
> * shlibs handling: why are shlibs not converted by dpkg-cross and only
> deps are? This means that when you create cross packages manually,
> such as libgcc1-armel-cross_all, you need to generate broken shlibs
> on libgcc1 in that package which will get translated by dpkg-cross
I believe shlibs part was merged to dpkg.
> * Do we want to provide both the cross built packages and dpkg-crossed
> cross-built packages? e.g. if you cross build gcc and get
> libgcc1-armel-cross_all from it, do we care to rebuild gcc with
> dpkg-buildpackage -aarmel + dpkg-cross to get a clean cross-built +
> dpkg-crossed libgcc1-armel-cross?
> doko suggested doing this, I agree that for a dpkg-crossed archive
> the latter is cleaner than the former.
You need both, cross-built (binutils-armel-cross, gcc-armel-cross) and
dpkg-crossed (libc, kernel headers,...). libgcc1 is dpkg-crossed in
first instance, so it fullfils libc dpkg-crossed dependencies (also
gcc-X.Y-base), then when you build the cross compiler, it outputs
libgcc1 and gcc-X.Y-base packages again (those are rebuild).
If you try to have a cross built gcc, to ran in the target, you need
libgcc1 as well, this was build using some other flags, IIRC,
REVERSE_CROSS, we haven't been doing such builds as we have dropped
Crush 2.0 release (next crossbuild release along Debian). This can
also be combined with 1st stage bootstrap, so the build is faster in
time and the only package needed is libgcc1.
Another suggestion we have though, but not work on it, is to provide
several libgcc1, so using a mechanism like update-alternatives we are
able to change compiler defaults, so crosstool could build code for
armv5tel by default or change it to be arm7, this can also be done
passing a switch when compiling, but people is not used to pass those
flags in their build systems.
>
>> [1] git clone git://emdebian.org/org/emdebian/git/buildcross.git
>> (I am unsure this works for anonymous users, it should work)
>
> (Does not and couldn't use http either.)
Moved to svn branch,
svn co http://www.emdebian.org/repos/current/emdebian/trunk/buildcross/branches/buildcross-ng/
I'll be out on the weekend. Have a nice day!
Kind regards,
--
Héctor Orón
[1] http://www.mail-archive.com/debian-embedded@lists.debian.org/msg04626.html
[2] http://wiki.debian.org/EmdebianToolchain
[3] http://wiki.debian.org/EmdebianToolchainAutobuilder
Reply to: