Differences between revisions 50 and 51
Revision 50 as of 2017-12-19 05:36:00
Size: 9369
Editor: ?HelmutGrohne
Comment: thank Manuel A. Fernandez Montecelo and Simon McVittie
Revision 51 as of 2018-05-07 14:21:11
Size: 9282
Editor: ?HelmutGrohne
Comment: move to salsa
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
The [[https://anonscm.debian.org/cgit/users/helmutg/rebootstrap.git/|source]] can be obtained using git: The [[https://salsa.debian.org/helmutg/rebootstrap.git|source]] can be obtained using git:
Line 12: Line 12:
git clone git://anonscm.debian.org/users/helmutg/rebootstrap.git
# or
git clone git.debian.org:/git/users/helmutg/rebootstrap.git
git clone https://salsa.debian.org/helmutg/rebootstrap.git


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 https://salsa.debian.org/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
    • Manuel A. Fernandez Montecelo for NMUing lots of packages or just poking them until maintainers fix them
    • Simon ?McVittie for his work on native issues

  • Many others! (Multiarch, Emdebian, etc.)


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


Something causes cross compiler libraries (lib*-alpha-cross) to depend on libc6.1 rather than libc6.1-alpha-cross. Thus they are uninstallable. (Jobs rebootstrap_alpha_gcc*_supported)


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.


Wookey is working on upstreaming all that stuff. The linux patches are too big to cherry-pick.


Someone needs to tell guile-2.0 how to cross build for hppa.

File conflict between libc6-dev and libc6-dev-hppa-cross (converted by dpkg-cross). Someone needs to fix dpkg-cross.


gnumach has no clue how to handle cpu type x86_64. Some needs to finish the porting, see https://www.gnu.org/software/hurd/open_issues/64-bit_port.html.


The stage3 build of hurd fails. It worked earlier. Someone needs to figure out why.


When built on amd64, the cross compiler package gcc-N-i386-linux-gnu:amd64 has a dependency on lib64gcc1. Since the latter is only available for i386, the dependency is unsatisfiable. It should be depending on libgcc1 instead. Something goes wrong in dpkg-shlibdeps.

Other builds simply fail running dpkg-shlibdeps as it fails finding e.g. libc.so.6. Why?

When building without disabling multilib, the stage2 pass of gcc-7 fails including <stdio.h> in the x32 multilib pass of libgcc.


Debian's glibc dropped support for ia64 as of wheezy.

Currently, reboostrap on ia64 is stuck at a dependency loop between GCC's internal libunwind implementation, and GLIBC. Work is being done on a GLIBC stub that will satisfy libunwind's requirements.


When built on amd64, the cross compiler package gcc-6-x86-64-kfreebsd-gnu:amd64 has a dependency on libc0.1. Since the latter is only available for kfreebsd-any, the dependency is unsatisfiable. It should be depending on libc6 instead. Something goes wrong in dpkg-shlibdeps.

When building with gcc-7, <stdio.h> goes missing during gcc stage2 while building the i386 multilib pass of libgcc. Why?


There is a dependency cycle between src:glib2.0 and src:gamin. Someone needs to break it.


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.)


When building with gcc-7, the cross compiler multilib library lib64atomic1-mips-cross ends up depending on libc6-mips64, which is arch:any. It should be depending on libc6-mips64-mips-cross instead.


src:libgpg-error lacks the lock object header.

src:jemalloc lacks LG_QUANTUM.

There is a file conflict bewteen the multilibs libc6-mips32-mips64-cross and libc6-mips64-cross. Someone needs to fix dpkg-cross.

When building with gcc-7, the stage2 cross compiler build fails. Why?


Someone needs to tell src:openssl what this architecture means.


Someone needs to tell src:openssl what this architecture means.


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.


Missing symbol __sanitizer_print_memory_profile while processing libasan as part of the stage3 cross compiler build.


Someone needs to tell src:openssl what this architecture means.


Linux support needs to be upstreamed. See https://lkml.org/lkml/2017/5/22/1058.


Debian's glibc dropped support for ia64.


Cross building glibc fails when using gcc-7. Why?


Cross building glibc fails when using gcc-7. Why?


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. Fixes are committed, but not released upstream.

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."


gcc-7 fails to build, because ./src/libmpx/mpxrt/mpxrt.h defines XSAVE_OFFSET_IN_FPMEM as sizeof (struct _libc_fpstate) and expects that struct to be defined by the libc. On glibc systems, it is defined in asm/ucontext.h. On musl, the struct is missing.

musl-linux-mips, musl-linux-mipsel

While building dash, checking for stdtod fails with:

/usr/lib/gcc/mipsel-linux-musl/7/../../../../mipsel-linux-musl/bin/ld: /tmp/ccM5bAHk.o: relocation R_MIPS_HI16 against __gnu_local_gp' can not be used when making a shared object; recompile with -fPIC