>>>>> "Wachholz," == Wachholz, Ruediger <Ruediger.Wachholz@siemens-enterprise.com> writes: > Hi David, Kyle, > thanks a lot for your explanations so far. For the moment i expect my > part to contribute to use the existing port and report problems. We'll > see whether i'm able to to some more. > For the moment i'd like to make use of your offer for more advice in > asking some follow up questions below: >>> >> We're evaluating to build an embedded system on powerpc e500v2 >> >>> (=powerpcspe) architecture. We made some tests using binary >>> powerpcspe >> sid from debian-ports >>> (http://wiki.debian.org/PowerPCSPEPort) and >> would like to >>> proceed. Actually our major concern is that the actual >> powerpcspe >>> port is based on sid/unstable which is no good base for a >> >>> commercial product. >>> > >>> >> For this reason we want to try to build the a powerpcspe port >>> from >> source based on a stable debian release (e.g. squeeze) and >>> i'm looking >> for some hints to get started. Can someone please >>> give me some hints >> on how to (cross)build the debian packages? >>> I'm pretty sure that there >> exists a simple debian command which >>> will work for most of the >> packages. >>> > >>> >> We could assume that a properly configured cross-compiler is >> >>> available, e.g. we use "make ARCH=powerpc >> >>> CROSS_COMPILE=/opt/codesourcery/bin/powerpc-linux-gnu-" to build the >>> >> kernel. Otherwise any hints on dealing with cross compiling are >>> also >> welcome. >>> > >>> > I don't think that a full debian base-system can be easily build >>> using > cross-compilation. As far as I understand, the usual way to >>> port debian > is to setup a build system and then proceed natively >>> building all > packages. >>> >>> Exactly right. Debian packages (at least right now) do not reliably >>> build from a cross-compile environment, most of them *MUST* be built >>> on a native system. The "Emdebian" project does cross compiling for >>> some limited subset of packages on a few architectures, and even >>> then they have thousands of patches to make it work at all. >>> >>> Furthermore, you can't reasonably crossbuild *any* Debian packages >>> with anything other than an "official" Debian-built cross-compiler. > Just for better understanding: could you please outline some technical > reasons why - Debian packages do not reliably build from a > cross-compile environment Many complex software packages make assumptions that are incompatible with cross-compilation. such as: programs compiled in the build process can be executed during the build process. Autoconf makes it even worse, since many autoconf feature detection macros use that assumption and fail during cross-compilatio. Most people don't test for cross-compilation, so never see such problems (although often they are easy to fix). > - crossbuild of Debian packages requires the "official" Debian-built > cross-compiler? No, it needs an official cross-compiling version of dpkg-buildpackage. Also, naturally it then also needs a whole bunch of target system libraries installed at some 'sysroot' directory. Management of sysroots for cross compilation again needs special debian cross-development tools (apt-cross, xapt, dpkg-cross, whatever). This is currently actively developed and redesigned, and i wouldn't consider it stable. If you can do without cross-compilation, you should do without cross-compilation to avoid problems. >>> >>> > By the way I'm going to use debian-powerpcspe for an embedded >>> system, > too. Already set up a pretty usable build systems on a >>> p2020rdb, based > on debian-ports sid+unreleased. > I'm using the p2020rdb as well. But actually i'm not successful to > setup a native build system using the debootstrap archive > http://download.breakpoint.cc/debian/powerpcspe-debootstrap-root.tar.bz2 > together with sources.list "deb http://ftp.de.debian.org/debian-ports/ > sid main". Even following your hint adding "deb > http://ftp.de.debian.org/debian-ports/ unreleased main" installation > of gcc fails as follows: [..] Please post your contents of /etc/apt/sources.list and /etc/apt/sources.list.d/*. I have the following lines in sources.list: deb http://ftp.de.debian.org/debian-ports sid main deb http://ftp.de.debian.org/debian-ports unreleased main and make sure you type 'apt-get update'. does it help? > Installation of gcc from "deb http://ftp.de.debian.org/debian-ports/ > unreleased main" has been working at about december 2010 i think. > Could you please help me to overcome above problems to setup a native > gcc? Maybe the mirror was during an update that moved files from 'unreleased' to sid (or vice versa) during your installation attempt? Just wildly guessing. Does it work currently? > I started using the kernel sources delivered by freescale: some > linux-2.6.32 together with about 50 patches. Some colleagues will have > to write drivers for our hardware, for me it would be easiest to stay > with 2.6.32. What kernel sources are you using as a base? You shouldn't worry about kernel versions. Debian rootfs generated via multistrap should happily boot on any modern kernel (as long as all debian-required features are present), no need to rely on official debian kernels. >>> Let me know if you have anything in particular you'd like to work >>> on, I'll give what advice I can! > I'll be happy to do so, here it is :-) > As i have not much experience with hardware specifics i still have not > really understood the implications of our choice for CPU p1021/p2020 > from freescale. From http://wiki.debian.org/PowerPCSPEPort i assumed > that the "exact" processor identification could be "e500v2", lacking > lwsync and requiring "--with-cpu=8548 --enable-e500_double > --with-long-double-128". A colleague of mine has the opinion that > codesourcerys compiler with option "-me500mc" would be best to compile > our own application, but on https://lkml.org/lkml/2011/3/8/386 i read > that "e500 is referring to the SPEstuff and e500mc cores are a whole > different beast with a regularFPU" (also mentioning a naming confusion > which i totally share). Could you shed some light on a CPU > "identification" and required compiler switches assuming use of > freescales p1021/p2020? If you go with debian, you should be fine using the included gcc-4.5 compiler without any additional otpions specifying cpu model. First make it work, then make it fast. cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
Attachment:
pgpLbPALjrFKP.pgp
Description: PGP signature