On Mon, 21 Mar 2011 09:55:26 +0100 Raphael Hertzog hertzog@debian.org wrote:

(Trimming the CC: feel free to drop patches@l.o if linaro-dev@l.l.o is more useful. Please keep debian-embedded in CC to reach me.)

Not knowing much about cross-compilation I had started with a sligthly different approach than you, mimicking exactly what was done for cross-compilation support.

09:48 < codehelp> buxy: vorlon: my original query related to not so much building a cross-compiler but building gcc-* to install and run on cross, i.e. reverse-cross where build=amd64,host=armel,target=armel 09:48 < codehelp> cross-compiler build=amd64,host=amd64,target=armel 09:48 < codehelp> doesn't give you a libgcc1 which can be used to satisfy dependencies of packages cross-built using the cross-compiler

Cross-building an entire distro, like Emdebian Crush, involved a long winded process: 0: Build gcc-4.* as an arm cross-compiler (not armel in those days but that's not important to the method) 1: Build build-dependencies of gcc using the cross-compiler 2: Build gcc-4.* as a normal package using the cross-compiler

The people who are most likely to be doing this now are Linaro. Emdebian Crush stalled after Lenny (and used ARM not armel), so the version of gcc-4.2 in Lenny should still build with the typical "dpkg-buildpackage -aarm". Later versions of gcc probably have other fixes which would cause the reverse cross build to fail, not due to the failure of the original patches but due to changes in gcc itself.

To create a fully bootstrap-able system, gcc does need to support the reverse cross and this will need testing in Multi-arch world.

Typically, gcc-4.* *should* be expected to build correctly just using: $ dpkg-buildpackage -a$arch

No special target specification (except internally in debian/rules etc.), no expectation of building a cross-compiler, just building it as if it is any other package which needs to be cross-built.

Of course, if libgcc1 can be made available in any other way than having to pretend that we actually want a native compiler on these systems (99% of the time we really don't), then everyone wins.

Neil (or anyone else knowledgable on the topic), can you review the patches and tell us what's really needed and most logical according to you?

Steve's patch:

• adds the multi-arch path at the start of the search paths
• adds them only for stantard cross-compilation (host != build) but not for the special cases used to detect a cross-compiler build

Intuitively this does sound the correct way to do it, especially as what I wanted from the original patch was a standard cross-build, not the special case of building a cross-compiler, but:

My patch:

• adds the multi-arch path before the cross-arch patch but after the standard search path

• add them in all cases where the cross-compilation paths are used

Putting the multi-arch paths after the default path should not matter as dpkg-shlibdeps skips libraries of non-matching architecture.

This is more in line with how it actually works out when trying to cross-build gcc itself.

I'm not sure of the benefit of putting the multiarch lib location in front of the default lib location. I'm not sure if having some i386 libraries in a multi-arch path and the main system amd64 libraries in a non-multi-arch path would actually matter (after all, the same libraries *should* get updated together). That's a "traditional" Multi-Arch question, so I'd defer to Steve on that one.

For cross-building, it's simply sufficient that the new multi-arch-cross paths precede the old dpkg-cross paths and both patches achieve this.

For the case of building a cross-compiler, Steve's experience tends to prove that adding the multi-arch path is not needed... but I don't see why it should be treated differently than the cross-arch paths.

Can you enlighten us?

For building a cross-compiler, Steve is correct - it doesn't matter.

For using that cross-compiler to cross-compile gcc itself, it will matter. Multi-Arch paths will be necessary to build a version of libgcc1 which can be installed on the target.