I read your recent post to debian-devel with great interest, as I've done some bootstrapping efforts in the past, and I'm currently in the middle of a "port" for the x32 ABI. In the past, what I've done (mostly privately) was to develop a script I called "pbuildd" which essentially just runs through the list of currently unbuilt packages and tries running pbuilder on them all, then installs anything that succeeds into a local repository and starts up the loop again. Then, when things got stuck, I just did a manual inspection of the unsatisfied dependencies to find the cycles, and chose one to break. In fact, I've just started uploading my current iteration of this to http://87.98.215.228/debian/ -- you might want to especially look at scripts/pbuildd which is the central script to run this loop. (And over time, it's gathered various optimizations to speed up the "installation into local repository" step, try to avoid invoking pbuilder if it can easily determine that certain Build-Depends aren't present at all, etc.)
Initially, when I needed to break a cycle, I would just build something by hand and stick it into the "partial" directory, but over time I started developing automated cycle-breaker scripts, which are currently under scripts/cb.inactive (the pbuildd script looks for them under scripts/cb). The scripts tend to become outdated over time, though, with a moving target, and I'm sure the current state is no exception. My personal heuristics for what I preferred were: first, prefer cycle-breaking which just removes Build-Depends which are there to build documentation. Then, prefer cycle-breaking which ignores Build-Depends on one or a few libraries which provide purely optional features. If I couldn't find anything of this sort, I'd just try to find the cycle-breaking point which would be (fuzzily) "least invasive" and "least likely to break the resulting packages, at least as far as packages that Build-Depend on them". In the past, pbuildd was mainly geared towards trying to build all of Debian (including the binary-indep packages) starting from a minimal chroot and with minimal extra package downloads, but on an established architecture. It was only recently that I started applying it to bootstrapping x32. The way I started that was actually: I started off mainly following the instructions from Linux From Scratch, though of course adjusting it to "cross-building" to x32 as necessary. I also inserted dpkg into the process as soon as possible after the first LFS stage creating the chroot with /tools, and from then on ran installs into temporary directories, and built dummy dpkg packages with no dependencies. Then, after the LFS builds were over, I started building real Debian packages from the actual .dsc source packages, and eventually had enough packages built in this way that I was able to do a debootstrap, and start the pbuildd process. (So yes, x32 might be a special case in that it runs on already widely available hardware, and I could develop from an existing Debian installation. But I'd imagine that was probably the case as well, though possibly to a smaller degree, for the amd64 and ia64 ports, and possibly other recent ports to new ABIs on existing hardware (armhf?).) As for specifics on the x32 port -- currently the most common issues I see (roughly from most common to least common) are: * Outdated libtool, which causes it to want to ld -r with the wrong -m target type. (And also ld -r more often than usual, because "getconf ARG_MAX" outputs "undefined" on x32 in certain circumstances, which the outdated libtool can't handle properly.) Of course this isn't an issue for packages that autoreconf at build time. * Issues which will hit every architecture once we switch to eglibc 2.16. Out of this, by far the most common is gnulib (other than very recent git versions) wanting to attach a warning to the "gets" prototype, which is no longer exported by default in eglibc 2.16. * Code still using sysctl(2), which is no longer supported in x32. * Code which unconditionally uses 64-bit asm snippets if __x86_64__ or __amd64__ is defined -- which causes assembler failures if one of the inputs or outputs is a long or a pointer type, and the asm snippet uses explicit "q" sizing suffixes (or there are other mismatches). -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C45igv-SnQcEz8v_A0vH=VKRJ+eFc7cwt2j5U=8rcyf...@mail.gmail.com
