Differences between revisions 40 and 41
Revision 40 as of 2016-02-20 15:53:36
Size: 6278
Editor: ?HelmutGrohne
Comment: update thanks and musl problems
Revision 41 as of 2017-03-13 18:56:30
Size: 6337
Editor: ?HelmutGrohne
Comment: thank jrtc27
Deletions are marked like this. Additions are marked like this.
Line 60: Line 60:
   * James Clarke for many insightful answers and patches


rebootstrap is a crude hack to test the bootstrappability of Debian architectures. In this context bootstrapping refers to building binaries for an architecture from source without using any pre-built binaries for that architecture. In the past 20 years about 20 architectures have been bootstrapped for Debian. At all times this has been a manual and non-repeatable process. rebootstrap is trying to address the very early bootstrap phase involving the gcc/eglibc dance.

The source can be obtained using git:

git clone git://anonscm.debian.org/users/helmutg/rebootstrap.git
# or
git clone git.debian.org:/git/users/helmutg/rebootstrap.git

One of rebootstraps major goals is to highlight bugs.

rebootstrap on jenkins.d.n

Contact Helmut Grohne or stop by #debian-bootstrap on OFTC if you have any questions.

DebConf15 Slides

Occasionally, rebootstrap works around limitations of packages by carrying patches locally. This raises the question of which patches are acceptable. Rules are:

  1. Patches must be intended for inclusion into the patched package and therefore should be filed as a bug against the relevant package.
  2. Patches beyond a couple of hundred lines are simply too long atm.


Without the following (non-exhaustive list of) people rebootstrap would not be where it is today. Thanks!

  • Porters for providing patches
    • arm64: Wookey
    • mips64el: ?YunQiang Su

    • or1k: Christian Svensson
    • ppc64el: Breno Leitao, Mauricio Faria de Oliveira, Erwan Prioul, IBM
    • x32: Daniel Schepler, Thorsten Glaser, Adam Borowski
    • musl-linux-any: Szabolcs Nagy
    • hurd-any: Samuel Thibault
    • kfreebsd-any: Christoph Egger and Steven Chamberlain
    • sparc64 and more: John Paul Adrian Glaubitz
    • nios2: Marek Vasut
    • uclibc-ng: Waldemar Brodkorb
  • Package maintainers for applying patches, in particular Matthias Klose for being quick
  • Infrastructure:
    • Holger Levson for administrating jenkins.d.n
    • ProfitBricks for donating the hardware running jenkins.d.n

    • Luca Falavigna for adding cross support to debomatic

    • Wavecon GmbH for donating the hardware running debomatic-*.d.n

  • Advice and other kinds of help
    • Guillem Jover for telling how to do things correctly
    • Bernhard R. Link for explaining difficult error messages
    • Peter Pentchev for fixing bugs that rebootstrap discovers tomorrow
    • Johannes Schauer for making things work in theory
    • Wookey, for NMUing lots of packages
    • Dima Kogan for maintaining cross-gcc-dev
    • James Clarke for many insightful answers and patches
  • Many others! (Multiarch, Emdebian, etc.)


Below is a non-exhaustive list of unsolved problems. Patches welcome.


libc6.1-dev:alpha conflicts with libc6-dev:amd64. Thus eglibc stage1 is not installable.

dpkg: regarding libc6.1-dev_2.18-4_alpha.deb containing libc6.1-dev:alpha:
 libc6.1-dev conflicts with libc6-dev
  libc6-dev:amd64 (version 2.18-4) is present and installed.

Wookey: It's correct for libc6.1:alpha to conflict with libc6-dev:i386 (because they have the same linux loader path: /lib/ld-linux.so.2


OABI is dead. There is no support for arm in linux (no target binary-libc-dev_arm), gcc-4.9 (target not supported) or glibc anymore.


Same as alpha.

dpkg: regarding libc6.1-dev_2.18-4_ia64.deb containing libc6.1-dev:ia64:
 libc6.1-dev conflicts with libc6-dev
  libc6-dev:amd64 (version 2.18-4) is present and installed.

Wookey: This makes no obvious sense as ia64 has a unique loader path: /lib/ld-linux-ia64.so.2. Is some other file conflicting?

In addition Debian's glibc dropped support for ia64.


binutils and gcc both support lm32 in trunk.

  • GCC - C/C++ compiler. Support for the ?LatticeMico32 has been added to GCC 4.5.0, but patches are available to add ?LatticeMico32 support to GCC 4.4.0.

  • Binutils - Assembler, linker and binary utilities; Binutils has supported the ?LatticeMico32 since version 2.19.

Blocker is no up-to-date linux port to the platform (an old port can be found at https://github.com/m-labs/linux-milkymist). The lm32 normally doesn't have a mmu, so needs ucLinux. Potentially more useful stuff at http://m-labs.hk/milkymist-wiki/wiki/index.php%3Ftitle=Milkymist_Linux_cheat_sheet.html and http://m-labs.hk/milkymist-wiki/wiki/index.php%3Ftitle=Linux.html

(The lm32 is a softcore created by Lattice for FPGA boards - see https://en.wikipedia.org/wiki/LatticeMico32.)


gcc as found in Debian sid for version 4.8 and 4.9 do not support or1k as a target. Thus gcc stage1 fails to configure. It is expected that this issue vanishes with future gcc upstream releases.


eglibc does not support this architecture:

dh_gencontrol -plibc6-dev
dpkg-gencontrol: error: current host architecture 's390' does not appear in package's architecture list (amd64 arm arm64 armel armhf hppa i386 m68k mips mipsel powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh4 x32)


All architectures beyond mips and mipsel fail to build the cross compiler due to wrong search paths.

datefudge: datefudge.c:77:5: error: conflicting types for 'gettimeofday'

libbsd: ../include/bsd/sys/cdefs.h:28:28: fatal error: sys/cdefs.h: No such file or directory

libelf: checking host system type... Invalid configuration 'mips-linux-musl': system 'musl' not recognized

libsigsegv: fault-linux-mips.h:30:70: error: 'mcontext_t {aka struct <anonymous>}' has no member named 'gregs'

  • fixed upstream in musl 1.1.11

libunistring: fseterr.c:72:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."