Status of cross-compilation in Wheezy?
Ryan Kuester <[email protected]>
| Newsgroups | gmane.linux.debian.devel.embedded |
|---|---|
| Message-ID | <[email protected]> |
Greetings all, Would someone please confirm or correct my understanding of the state of cross-compilation in Wheezy? Here's what I've synthesized from wikis, blogs, e-mail archives, and firsthand experience: With Wheezy comes the beginnings of multiarch, an exciting new world in which, e.g., the armel package of libexpat1 can be installed on an amd64 workstation via apt-get install libexpat1:armel or in some cases apt-get build-dep -a armel $other Theoretically, that armel library can be used by a cross-compiler; *however*, that glorious future is not yet here. The cross-compilers in the http://emdebian.org/debian Wheezy repository do not yet look for foreign libraries in multiarch paths[1]. Thus, and perhaps for additional reasons, multiarch is not yet of much benefit to cross-compilation in Wheezy, at least not with the cross-compilers from emdebian.org/debian. Instead, those cross-compilers still require that foreign libraries be installed via xapt, which generates -cross packages with, e.g., headers in /usr/arm-linux-gnueabi/include rather than the multiarch-correct path /usr/lib/arm-linux-gnueabi. The current plan is to create new cross-compilers which build from source and can become citizens of the Debian archive itself, rather than create additional cross-compilers via the old method. These new cross-compilers, in addition to building from source, will find foreign libraries which are installed in multiarch paths. They don't exist now, however, and won't exist in time to be released in Debian Wheezy. Thibaut Girka worked on this during GSoC 2012, but that work is incomplete in some way and the resulting cross-compilers were not put into the emdebian.org/debian repos. It's likely I've misunderstood some things, and boldly misstated them above. Thank you in advance for putting the record straight. -- Ryan -- 1. In some cases, the compiler gets a working library path anyhow via pkg-config, but not necessarily a working header path.