Dnia czwartek, 1 lipca 2010 o 18:44:26 Wookey napisał(a):
+++ Marcin Juszkiewicz [2010-06-28 16:06 +0200]:
Dnia piątek, 18 czerwca 2010 o 17:15:59 Marcin Juszkiewicz napisał(a):
Latest version of cross toolchains are available in prebuilt form on:
Marcin. I've been trying to get round to reading stuff and find out what was what but have failed so far. It's proably quicker to just ask you:
Can you tell me what you have done to the toolchain build process.
I am familiar with the existing cross-build mechanisms as used in the emdebian toolchains and the buildcross tool we use to build them. But it looks to me like you have moved stuff around and changed targets and things and I would like the high level view on what is changed and why.
One of things which I did was merging code used for native builds/packaging with cross one. In result we got less packaging code to worry and cross packages are improved now:
- libraries have -dbg packages - libmudflap is cross built
Also what decisions have been made about using existing or sysroot or multiarch paths or some combination of those in default search paths.
I did not changed any of those.
Do we still have work to do to make the cross-toolchains buildable in-archive by the buildds?
Yes, this has to be done. I have ugly patch which adds stage1 to eglibc (attached - build will fail on packaging step), managed also to build stage1/stage2 in gcc-4.5 but in style which needs to be rewritten totally (attached - use by "fakeroot debian/rules stage1_install").
Or is that done?
If it is done have you used the scheme worked out by Doko and Hector at last years Debconf, or some new scheme?
I asked Matthias (doko) about it and he told that talk was mainly about merging cross code with native one and that part is already done (but I am finding small improvements from time to time). Second part was biarch and here nothing got changed.
Has any progress been made on making it easier to set the default cpu build options without building a whole new toolchain?
Not that I know.
Some of these things affect other tools (like dpkg-cross and multiarch transition - second stage (cross building)), and I'd just like to see which choices have been made and why so I can see if there are any problems coming down the track.
Most of my already done work does not change anything related to a way how of building cross toolchain. Binutils have it easier now as "binary-cross" target got merged into "binary" one but note about it is printed if someone tries old way.
There are some tricky transitions which it would be nice not to make too much of a mess of, as it is likely to be a bit painful whatever we do, especially if there is skew between Debian and ubuntu.
All my changes lands in Debian's svn area which keeps gcc packaging.
Cheers for any clues you can give me to get me up to speed.
Regards,
On Fri, Jul 02, 2010, Marcin Juszkiewicz wrote:
I am familiar with the existing cross-build mechanisms as used in the emdebian toolchains and the buildcross tool we use to build them. But it looks to me like you have moved stuff around and changed targets and things and I would like the high level view on what is changed and why.
FWIW, the high-level view is in the blueprint; I think it even got recorded at UDS. https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers https://wiki.ubuntu.com/Specs/M/ARMCrossCompilers
Also what decisions have been made about using existing or sysroot or multiarch paths or some combination of those in default search paths.
I did not changed any of those.
So on this topic: https://bugs.launchpad.net/gcc-linaro/+bug/598389
I am not exactly sure which source Peter used for his cross-compiler. Perhaps affects Marcin's packaging as well, or maybe not.
In the end, I think the cross-compiler should look in the sysroot, and /usr/$triplet should be the default sysroot.
Has any progress been made on making it easier to set the default cpu build options without building a whole new toolchain?
Not that I know.
I dont think that makes much sense. If you change the ABI in anyway, you want your libgcc1 to pick that up; for instance if you built an armv7 cross-compilers and you would like it to target armv5, it wont work unless you rebuild libgcc1, and even if it works in the other direction you want to rebuild libgcc1 to benefit from it.
There are case which allows not to rebuild such as changing from -O2 to -O3/Os, or adding some -fflags, or adding a different -mtune=foo. I'd still rebuild libgcc1 if I were to change that, but you could in theory use something like hardening-wrapper in your buildd chroot to set any flags you like.
-
Loïc Minier -
Marcin Juszkiewicz