On 2010/03/24 17:50, "Sebastian Andrzej Siewior" <sebast...@breakpoint.cc> wrote: > * Moffett, Kyle D | 2010-03-23 17:52:57 [-0500]: >> Ah, my apologies. I'd actually already seen that one, but wasn't paying >> enough attention when submitting the bugreport. > > I saw in your earlier bug report that you don't have everything built > (yet). At [0] I have more or less complete port of an older lenny > snapshot. However, the Debian name is different. I recall that the > crossbuild had some dependencies wrong and -fstack-protector did > something wrong. Watch out if you building something cross :)
I've actually spent a lot of the last couple days fighting with the big shell-script-based tool I wrote to help manage our Debian "fork" (for our custom hardened appliance), although I do have quite a bit more crossbuilt now. I had to go back and re-build 6 or 7 of the packages about 5 times because of mis-builds associated with bugs in the portion that imports source packages into uniform Git repositories. The tool is available from a Git repository, although I have no idea how useful it's liable to be to anybody else since it's almost completely undocumented: git://opensource.exmeritus.com/daprads/latest.git http://opensource.exmeritus.com/git/daprads/latest.git [gitweb,smart-http] We unfortunately have a number of internal product requirements that basically force me to rebuild everything for squeeze anyways. As an aside, it looks like squeeze has has a fair amount of cross-compiling improvements made to it, so a lot more stuff cross-compiles nicely. At this point I'm trying to crossbuild enough stuff that I can create an NFS root filesystem using "debootstrap --foreign --architecture=e500". With the exception of the cross-compile dependency hell, the following seems to cross-build most packages nicely: dpkg-buildpackage -us -uc -ae500 -nc -b The only annoyances I run into on a regular basis (aside from the occasional package that simply utterly fails to cross-compile on the first shot): * CDBS seems to do "./configure CC=${target}-gcc [...]" which utterly breaks any tools that need to be built on the host. It also runs "make check", which again fails miserably on a cross-compile: The fix always seems to be to add the following at the appropriate spot in debian/rules: ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) DEB_MAKE_CHECK_TARGET := else DEB_CONFIGURE_SCRIPT_ENV := endif * Other packages have the same "make check" problem, again fixed with a conditional on cross-compiling * Some few packages have bad configure scripts that silently make invalid assumptions when you're cross compiling because they can't actually run their test. For example, libgcrypt needs: DEB_CONFIGURE_SCRIPT_ENV := ac_cv_sys_symbol_underscore=no If the configure script just died hard and said "Figure out this variable and pass it to me dammit", that would be OK... but silently continuing and failing with weird linking errors later is totally unhelpful. * Bootstrapping from source is painful because of dependency chains like: dpkg => libselinux => ruby (oh god the dependency horror) apt => curl => openldap => perl (aaaargh... runaway!!!) Since dpkg-buildpackage doesn't know how to check dependencies for cross-compiled things, this is usually actually pretty easy to work around by just "forgetting" to install openldap and letting cURL build without LDAP support. This does mean that my bootstrap packages have OpenLDAP and SELinux and a variety of other features turned off for the moment, but once I get a booted native Debian environment I can build everything else I need native (stuff like Perl, etc). >> The "spe" in the arch triplet refers to the set of extensions to the >> PowerPC/POWER instruction set that are implemented by the MPC85xx-series >> processors. The e500-series cores themselves conform to Power ISA v.2.03, >> but the particular implementation of floating-point support is quirky enough >> that it requires a separate ABI. > > I would not use the term quirky. It is not the "traditional" FPU instead it > is a different one. I think it is described as embedded FPU. ARM on the > other hand has a few more "choices". I think the fact that every other PowerPC CPU family ever made has a traditional FPU while the e500-seires has this weird "SPE" thing makes the e500 qualify as "quirky". The fact that you have 64-bit GPRs used for floating point while only the lower 32-bits can be used by the integer operations also qualifies :-D. >> So it is my belief that "e500" is the correct and appropriate name for the >> architecture. > > Which brings me to the following question: There are currently two types > of the core: e500v1 and e500v2. The latter implements also the floating > point type double in hardware while the former doesn't. Which one did > pick? I would prefer to go for e500v2 since I don't think that there > much e500v1 around plus I don't belive that those are used in multimedia > like applications. > And it would be probably nice to mark this in arch name. Our hardware's built using the Freescale P2020, which appears to be an e500v2 core. I can't find a detailed list anywhere summarizing which parts are e500v1 versus e500v2. Judging from this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007 The e500v1 was never very popular and all of the available parts today support double-precision floating point GPRS. With that said, I'm actually not sure if my current compiler is built properly to enable use of the double instructions. If it's not, that's going to be an essential part of my "rebuild the world with whatever arch name the dpkg maintainers want" project. Looking into it more, that URL actually does list that some e200 CPUs support single-precision floating point. On the other hand, the entire e200 series appears targeted at automotive designers for engine management, brake control, etc, and as such is highly unlikely to end up with Debian on it. >> To be blatantly honest, I personally would really prefer if that's the final >> name as it would save me about 3 days worth of re-bootstrapping packages >> using a different architecture token. If you all think something else is >> definitely more appropriate I will however defer to your judgment (with some >> amount of grumbling and complaining). > > I hope that you don't think that I am a total ass if I say that google > should have help find you [3]. No offense please. I would love to have > someone on my side so that port is not just a one man show :) No offense taken! I had actually started working on my "e500" port before I found your bugreport; given the comments from the other DD's on the port naming I think "gnuspe" is unlikely to be workable long-term. > Anyway. My plan is to settle down on a name and get everything rebuilt > for debian-ports. So even if we stick to e500 as you wish everything > will be rebuilt by buildd or atleast by manual sbuild anyway. Oh absolutely! My problem right now is I don't have a running install on my dev hardware right now and to get one I have to build a lot of things by hand. Internally we've got automated rebuildd and reprepro servers that we use for testing our hardening on bog-standard x86-64 servers. Once I get an e500 board up and running I'm dropping the cross-compiler package and icecc on all of those systems. I'll then replace /usr/bin/gcc and /usr/bin/g++ on the e500 board with versions that call "icecc" or "distcc" or whatever as "powerpc-linux-gnuspe-{gcc,g++}". That should speed up my build times considerably by sending a lot of the build jobs across gigabit to the beefy servers. Long-term that's the environment that we plan to provide for a Debian buildd anyways. > So what about keeping powerpc somewhere in the name? I think it > is a good idea to denote the double type (I would prefer not to switch > it once we have a port). So powerpce500v2 would make it clear, wouldn't > it? It is hard to read so maybe e500v2 isn't that bad at all. Yeah... IMNSHO it should be either "e500" or "e500v2" just to keep it from being so dang hard to type. Hopefully we've provided enough information so the dpkg devs can pick something and we can get on with the official port? Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
