gregorr / musl-cross Goto Github PK

A small suite of scripts and patches for building musl libc cross compilers.

Shell 100.00%

musl-cross's Introduction

About musl-cross

This is a small suite of scripts and patches to build a musl libc cross-compiler. ~~Prebuilt cross and native compilers are available at http://musl.codu.org/~~

For the impatient, ./build.sh should build a cross compiler to /opt/cross/<arch>-linux-musl, no muss, no fuss. Otherwise, you can edit config.sh to make cross-compilers to other architectures, and even copy config.sh to another directory then run build.sh from there to avoid polluting the source dir.

Project Scope

Supported are GCC 4.0.3 until 5.3.0. for newer GCCs check out the musl-cross-make project.

Notes on building normal cross compilers

For ARM, you must set the triple to arm-linux-musleabi (eabi is the important bit here)

You can set versions of binutils, GCC or musl in config.sh with:

  BINUTILS_VERSION=<version>
  GCC_VERSION=<version>
  MUSL_VERSION=<version>

You can set configure flags for each step:

  BINUTILS_CONFFLAGS=...
  GCC_BOOTSTRAP_CONFFLAGS=...
  MUSL_CONFFLAGS=...
  GCC_CONFFLAGS=...

You can use a git checkout of musl with:

  MUSL_VERSION=<git tag or commit>
  MUSL_GIT=yes

If you do not have the GMP, MPFR and/or MPC development libraries on your host, you can build them along with GCC with a config.sh line:
```
  GCC_BUILTIN_PREREQS=yes
```

Recommendations

If you would like to target a specific CPU revision, usually this is done by GCC configuration options like so:
```
  GCC_BOOTSTRAP_CONFFLAGS="--with-cpu=armv4t"
  GCC_CONFFLAGS="--with-cpu=armv4t"
```
For ix86 however, it is more common to do this by the target name, e.g. i486-linux-musl instead of i686-linux-musl.

Upgrading cross compilers

It is possible to upgrade the musl version in a musl-cross cross compiler without rebuilding the entire cross compiler prefix from scratch. Simply download and extract the new version of musl, then configure it like so:

./configure --prefix="<prefix>/<triple>" CC="<triple>-gcc"

Where <prefix> is the prefix the cross compiler root was installed/extracted to, and <triple> is the GNU-style target triple (e.g. i486-linux-musl).

Other scripts and helpers

config.sh is an example configuration file. In many cases, it will do exactly what you want it to do with no modification, which is why it's simply named config.sh instead of, e.g., config-sample.sh
extra/build-gcc-deps.sh will build the dependencies for GCC into the build prefix specified by config.sh, which are just often a nice thing to have. It is of course not necessary.
extra/build-tarballs.sh builds convenient musl cross-compiler tarballs in a rather inconvenient way. It first builds a musl cross-compiler to the host platform (e.g. i686), then it uses that to build static cross-compilers to various platforms. As a result, building e.g. three cross-compiler tarballs involves eight compiler build phases (read: this is slow). However, the resultant tarballs are cross-compilers statically linked against musl, making them stable and portable.
config-static.sh is an example configuration file for building a static cross-compiler. You can use this if, e.g., you already have a build of musl (and so have musl-gcc) but would like to make a complete, static cross-compiler based on that, or if you already have a musl cross-compiler (and so have <arch>-linux-musl-gcc) but would like to make a static cross-compiler itself compiled against musl.

Requirements

musl-cross depends on:

shell and coreutils (busybox is fine)
mercurial or git (for checkout only)
wget (busybox is fine)
patch
gcc
make
awk (busybox is fine)

The following are GCC dependencies, which can be installed on the host system, or installed automatically using GCC_BUILTIN_PREREQS=yes:

gmp
mpfr
mpc

Building GMP additionally requires m4.

Compiler/Arch Compatibility Matrix

	i?86	x86_64	x32	mips	powerpc	arm7	armhf	mb	sh4	or1k
4.4.7	yes	yes		yes	yes	yes
4.5.4	yes	yes		yes	yes	yes
4.6.4	yes	yes		yes	yes	yes
4.7.4	yes	yes		yes	yes	yes	yes		yes
4.8.5	yes	yes	yes	yes	yes	yes	yes	yes	yes
4.9.3	yes	yes	yes	yes	yes	yes	yes	yes	yes
5.3.0	yes	yes	yes	yes	yes	yes	yes	yes	yes	*

* or1k requires integration of a patch (issue #61)

musl-cross's People

Contributors

Stargazers

Watchers

musl-cross's Issues

building binutils 2.24 fails without bash installed

/opt/musl-cross/binutils-2.24/opcodes/configure: .: line 12683: can't open '../../opcodes/configure.host'
/opt/musl-cross/binutils-2.24/gas/configure: .: line 12682: can't open '../../gas/configure.host'

the cause is this bug
https://sourceware.org/bugzilla/show_bug.cgi?id=16370
sabotage-linux/sabotage#198
sabotage has a fix for it
sabotage-linux/sabotage@094a4e1

Patches for GCC 8.2.0?

I'm coming across several errors in GCC 8.2.0, probably as the result of inhibit_libc being set. Any suggestions?

buildroot ppl are complaining about sysroot disabled in default config

http://openwall.com/lists/musl/2014/06/28/6

Missing hashes for tarballs

WARNING: no checksum file for gmp-6.1.0.tar.bz2 found, please report!

Also missing are mpfr-3.1.4.tar.bz2 and mpc-1.0.3.tar.gz

sh4 build fails with 4.7.4

it's probably easy to fix:

../../gcc/gcc.c:1243:53: error: expected '}' before 'MUSL_DYNAMIC_LINKER'

on which we find:
static const struct spec_list_1 extra_specs_1[] = { EXTRA_SPECS };

latest 4.7.x release is 4.7.4, not 4.7.3

gmplib.org URL results in 404

The url in defs.sh points to http://gmplib.org/download/gmp/archive/. There is no GMP_VERSION=6.1.0 tarball in that directory. However, there is in http://gmplib.org/download/gmp/.

musl 0.9.15 is out.

Please use HTTPS URL in GitHub description

The URL in the GitHub description is already redirected to HTTPS.

$ curl -I http://bitbucket.org/GregorR/musl-cross
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Date: Fri, 11 May 2018 13:53:44 GMT
Location: https://bitbucket.org/GregorR/musl-cross
Connection: Keep-Alive
Content-Length: 0

It’d be great if you updated the URL in the description.

GCC build fails due to not finding mpfr.h

checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations.  Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/.  See also
http://gcc.gnu.org/install/prerequisites.html for additional info.  If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files.  They may be located in separate packages.
+ die Failed to build gcc-4.7.1
+ echo Failed to build gcc-4.7.1
Failed to build gcc-4.7.1
+ exit 1

TODO: integrate 5.3.0 openrisc patch

https://gist.github.com/rofl0r/5d1a0dad03beb62027df326fb16e9a8d

for integration musl-generic parts need to be removed

volunteers ?

gcc 4.7.3 patch misses powerpc specific hunk existent in 4.7.2 patch

14e862c#commitcomment-6901526

x86_64 toolchain places libstdc++.so and others in lib64 instead of lib

should be lib/ (there's no /lib64 in the musl world)

Does not gacefully handle partially downloaded/corrupt files or paritally extracted archives

Having any of them (an the first usually leads to the second) results in a failure.

provide a clean.sh or similar so a fresh build can be started

i changed ARCH and CC_BASE_PREFIX to build another cross compiler but that seems to fail due to leftover builddir

musl 1.1.2 is out

GCC 4.8.x defaults to DWARF 4, which needs bleeding edge tools

binaries with dwarf4 debug data are mishandled by tools such as gdb 7.4 and dwarfdump. only the most bleeding edge gnu tools are able to deal with it properly.
thus, we should force the default to be dwarf2 via

  --with-dwarf2           force the default debug format to be DWARF 2

if someone really needs dwarf4, he can enable it explicitly with -gdwarf-4 ; at least in the case of C dwarf-2 is totally sufficient but takes 3 times less space in the .debug section.

dl_iterate_phdr patch missing

https://github.com/rofl0r/sabotage/blob/master/KEEP/gcc473-unwind-dliterate.patch

plus

http://sprunge.us/IYiU

it's needed for proper C++ exception unwinding, at least on arm, but it's advantageous to have it everwhere

musl 1.1.3 is out

if possible when distributing the binary downloads, the 2 issues raised by the buildroot ppl should be adressed
#30
#31

unbloat crtstuff from gcc

rich felker suggests the following change to musl-cross:
http://openwall.com/lists/musl/2014/06/16/2

latest musl-cross precompiled downloads lack kernel header include dirs

using the prebuilt downloads:

/tmp/mips-sf-linux-musl $ find . -name linux
/tmp/mips-sf-linux-musl $

using my self-built toolchain:

$ find /home/rofl/musl-cross-4.8.3/mips-sf-linux-musl/ -name linux
/home/rofl/musl-cross-4.8.3/mips-sf-linux-musl/mips-sf-linux-musl/include/linux

GCC 5.2.0 cross compile with musl1.1.10 build failure

Hi
I'm trying to build toolchain for my custom OS on ARM.
I hope that I have done all required changes.
While compiling GCC 2nd stage, I get following build failure from libstdc++:

checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
gmake[1]: *** [configure-target-libstdc++-v3] Error 1

AR cannot find plugin

Not sure if this is a problem in musl-cross but I am getting:

x86_64-linux-musl-gcc-ar: Cannot find plugin 'liblto_plugin.so'

I add the issue here because liblto_plugin.so is packaged with gcc and this is a cross compiled gcc

-fstack-protector[-all] causes SEGV with small programs calling only a noreturn func

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245

gcc generates a stack protector prologue accessing TLS, but not the epilogue which would pull in the TLS init code, when a noreturn func like exit() is called.
this causes small configure checks to fail when -fstack-protector[-all] is active.

Building a C++ program native to the host

Trying to build fish shell against musl. I have downloaded the pre-compiled tools from the google drive but I am having trouble figuring out how to build a C++ program with x86_64-musl-linux-c++. I get a lot of warnings and finally an error:

parser_keywords.cpp: In function 'bool parser_keywords_is_reserved(const wcstring&)':
common.h:244:75: warning: missing sentinel in function call [-Wformat=]
 #define contains( str, ... ) contains_internal( str, 0, __VA_ARGS__, NULL )
                                                                           ^
parser_keywords.cpp:55:12: note: in expansion of macro 'contains'
            contains(word,
            ^
x86_64-musl-linux-c++ -static -g -O2 -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fno-exceptions -Wall -Wno-sign-compare  -DLOCALEDIR=\"/test/share/locale\" -DPREFIX=L\"/test\" -DDATADIR=L\"/test/share\" -DSYSCONFDIR=L\"/test/etc\" -DBINDIR=L\"/test/bin\" -DDOCDIR=L\"/test/share/doc/fish\"  -L/test/lib64 -L/test/x86_64-linux-musl/x86_64-linux-musl/include -I/test/include -DFISH_BUILD_VERSION=\"2.2.0\"  -c -o iothread.o iothread.cpp
iothread.cpp: In function 'bool iothread_wait_for_pending_completions(long int)':
iothread.cpp:249:20: error: aggregate 'iothread_wait_for_pending_completions(long int)::timeval tv' has incomplete type and cannot be defined
     struct timeval tv;
                    ^
iothread.cpp:254:5: error: 'fd_set' was not declared in this scope
     fd_set fds;
     ^
iothread.cpp:255:14: error: 'fds' was not declared in this scope
     FD_ZERO(&fds);
              ^
iothread.cpp:255:17: error: 'FD_ZERO' was not declared in this scope
     FD_ZERO(&fds);
                 ^
iothread.cpp:256:20: error: 'FD_SET' was not declared in this scope
     FD_SET(fd, &fds);
                    ^
iothread.cpp:257:51: error: 'select' was not declared in this scope
     int ret = select(fd + 1, &fds, NULL, NULL, &tv);
                                                   ^
make: *** [iothread.o] Error 1

README could be improved by adding a short explanation of "native" usage scenario

along the lines of
"if musl-cross is used to create libs for a glibc hostsystem of the same architecture with the intention to run them on the same box,
/lib/ld-musl-$ARCH.so.1 should be created as a symlink to $cross/.../lib/libc.so and /etc/ld-musl-$ARCH.path created with a line containing the $cross libdir"

that's needed to run for example a C++ hello world.

binutils build fails when makeinfo is missing

WARNING: `makeinfo' is missing on your system.  You should only need it if
         you modified a `.texi' or `.texinfo' file, or any other file
         indirectly affecting the aspect of the manual.  The spurious
         call might also be the consequence of using a buggy `make' (AIX,
         DU, IRIX).  You might want to install the `Texinfo' package or
         the `GNU make' package.  Grab either from any GNU archive site.
make[3]: *** [bfd.info] Error 1
make[3]: Leaving directory `/media/3T/git-mirror/musl-cross/binutils-2.23.2/build1/bfd/doc'

changes needed to support x32

in order to build for x32, which doesn't use an explicit triplet (it needs x86_64 with multilib support), the following changes are needed:

if arch == x32 then triplet=x86_64-x32-linux-musl
the triplet x86_64-x32 is used internally by glibc[1] and it makes binutils build and gcc "magically" (because they detect it as x86_64) do the right thing. the musl port will use "x32" as arch tho.
this has the additional advantage that when doing several builds into the musl-cross prefix, the x86_64 will not be overwritten and a x86-64-x32... dir will be created.
when building gcc2, --disable-multilib has to be replaced with --with-multilib-list=mx32
recent kernel headers (already done)

[1] https://sourceware.org/glibc/wiki/x32

gcc 4.8.3 broke microblaze

build/genopinit ../../gcc/config/microblaze/microblaze.md \
  insn-conditions.md -htmp-opinit.h -ctmp-opinit.c
echo timestamp > s-attr-common
build/genextract ../../gcc/config/microblaze/microblaze.md \
  insn-conditions.md > tmp-extract.c
/bin/bash ../../gcc/../move-if-change tmp-emit.c insn-emit.c
echo timestamp > s-config
build/genoutput ../../gcc/config/microblaze/microblaze.md \
  insn-conditions.md > tmp-output.c
echo timestamp > s-codes
build/genpeep ../../gcc/config/microblaze/microblaze.md \
  insn-conditions.md > tmp-peep.c
build/genrecog ../../gcc/config/microblaze/microblaze.md \
  insn-conditions.md > tmp-recog.c
../../gcc/config/microblaze/microblaze.md:2164: warning: operand 1 missing mode?
../../gcc/config/microblaze/microblaze.md:516: '@' is redundant for output template with single alternative
../../gcc/config/microblaze/microblaze.md:1123: error: undefined machine-specific constraint at this point: "Q"
../../gcc/config/microblaze/microblaze.md:1123: note:  in operand 0
../../gcc/config/microblaze/microblaze.md:1123: error: undefined machine-specific constraint at this point: "Q,r"
../../gcc/config/microblaze/microblaze.md:1123: note:  in operand 1

works with 4.8.2

this commit seems to have broken it
http://repo.or.cz/w/official-gcc.git/commitdiff/a421c18ad013091c30f053e45e217e7d80213e90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61388

gcc 4.8.4 and 4.7.3 patches miss LINK_SSP_SPEC hunk

could they please be regenned ?

musl 1.1.1 is out

gcc 4.9.2 is out

the codegen bugs affecting musl were finally fixed, so it may be interesting to integrate it now.

gcc installs unnecessary libs

for example libiberty.a
this may cause build error of other gnu sw using libiberty when they expect another version (the one in their source tree, which only gets build when libiberty is not already installed), and wastes space.

some other things like libatomic can possibly be removed as well.

Please use working server for GMP

Currently gmplib.org does not resolve causing a build failure.

$ dig @8.8.8.8 gmplib.org

; <<>> DiG 9.9.6-P1 <<>> @8.8.8.8 gmplib.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27102
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gmplib.org.			IN	A

;; Query time: 11 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri May 11 14:59:48 CEST 2018
;; MSG SIZE  rcvd: 39

I’d be great if you used an alternative server like https://ftp.gnu.org/pub/gnu/gmp/.

musl 1.1.12 is available

musl build fails on mac

http://pastebin.com/qjh8Wn5p

apparently mac's ar program cant create empty archives.
this could easily be circumvented if musl-cross uses the CROSS_COMPILE variable for musl, so musl will pick up the cross ar.

Add patches for GCC 5.4.0

Add patches for GCC 5.4.0 since it's the latest one available for the 5.x branch. Also, add the patches to allow to compile it with GCC 6.x.x and newer.

i486 toolchain (and maybe others) fail with -fPIE -fstack-protector-all

test.c

int main() {return 0;}

i486-linux-musl-gcc test.c -fPIE -fstack-protector-all
/tmp/ccEkagdJ.o: In function `main':
test.c:(.text+0x28): undefined reference to `__stack_chk_fail_local'
/home/rofl/musl-cross-4.8.3/i486-linux-musl/lib/gcc/i486-linux-musl/4.8.3/../../../../i486-linux-musl/bin/ld: a.out: hidden symbol `__stack_chk_fail_local' isn't defined
/home/rofl/musl-cross-4.8.3/i486-linux-musl/lib/gcc/i486-linux-musl/4.8.3/../../../../i486-linux-musl/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

interestingly, the gcc build is aware of the need of libssp_nonshared.a and creates it from ssp-local.c, and it even installs it into lib/.
however, it fails to add it to its linker invocation when it's needed.

i486-linux-musl-gcc test.c -fPIE -fstack-protector-all -lssp_nonshared

works.
alpine linux uses the following patch for the same issue:
http://git.alpinelinux.org/cgit/aports/tree/main/gcc/gcc-4.8-musl-libssp.patch

build speed could be improved significantly by using "-O0 -g0" for the first (throw-away) gcc

musl 1.0.0 is out (and there's a ton of interest due to the release publicity)

downloading fails with busybox wget linked against musl

just putting the -O option first fixes it

$ busybox wget -c http://ftp.gnu.org/gnu/binutils/binutils-2.24.tar.bz2 -O binutils-2.24.tar.bz2.part
Connecting to ftp.gnu.org (208.118.235.20:80)
binutils-2.24.tar.bz 100% |*******************************| 22184k  0:00:00 ETA
wget: not an http or ftp url: -O

$ busybox wget -O binutils-2.24.tar.bz2.part -c http://ftp.gnu.org/gnu/binutils/binutils-2.24.tar.bz2
Connecting to ftp.gnu.org (208.118.235.20:80)
binutils-2.24.tar.bz 100% |*******************************| 22184k  0:00:00 ETA

this is probably a bug in busybox wget; but it's easy enough to work around

Where did the prebuilt toolchains go?

This isn't quite directly related to this project, but the README mentions that http://musl.codu.org/ is the page for prebuilt toolchains and that https://bitbucket.org/GregorR/musl-cross/downloads/ is obsolete. Yet at the http://musl.codu.org/ site, there is only a broken link to a google hosted page.. are you still maintaining binary builds of musl toolchains or is that a thing of the past?

binutils 2.24.90 snapshot fixes longstanding trouble with ARM

a nasty assertion error ( sabotage-linux/sabotage#186 ) plagued me on ARM with usage of -ffunction-sections, which is a nice way to create binaries with minimal size (in sabotage's default CFLAGS), almost equivalent to -flto which causes a 3x increase in compile and link time.
the latest binutils snapshot fixes it.

ftp://sourceware.org/pub/binutils/snapshots/binutils-2.24.90.tar.bz2

it's now also used by sabotage and works well on x86_64 and ARM where i tested it.

Maintained fork

@GregorR is currently (since at least 2 months) not responding to emails.
Until he's back, the fork available under this URL https://github.com/sabotage-linux/musl-cross
will be maintained.

build speed could be improved by using the .xz version of the kernel tarball

extracting bz2 takes about 3-4 times as long as .xz; and additionally it takes longer to download as it is ~30% bigger.

musl is by default built without optimization

--enable-debug currently means "-O0 -g" (which is unexpected and will be changed) so you end up with an unoptimized musl build in the default config,
unless you add something like MUSL_CONFFLAGS=--enable-optimize=size to your config.sh. this results in very slow and very big code emitted, which probably gives a wrong impression to first-time users.

gas / binutils 2.27 generates invalid ELF files

The Heads project is having problems building musl-cross on modern systems due to an incompatible change in libelf. linuxboot/heads#618 (comment)

The problem is also described here: https://wiki.gentoo.org/wiki/Binutils_2.32_upgrade_notes/elfutils_0.175:_unable_to_initialize_decompress_status_for_section_.debug_info

Starting from dev-libs/elfutils-0.175 libelf writes compressed section alignment according to the ELF spec (see https://sourceware.org/PR23916). Unfortunately GNU assembler (gas from binutis-2.31.1 and older) writes non-conformant alignment. This means that libelf processing of such ELF files "corrupts" object files for binutils-2.31.
binutils-2.32 now writes conformant ELF alignments (see https://sourceware.org/PR23919) but the result is not compatible to binutils-2.31.

The symptom that we encounter is that musl-cross-gas produces invalid ELF files for the Linux kernel's .S assembly programs, which are corrupted when they are processed by the ORC unwinder linked against the system's libelf:

/heads/build/../crossgcc/x86_64-linux-musl/bin/x86_64-linux-musl-objdump: arch/x86/lib/memmove_64.o: File format not recognized
/heads/build/../crossgcc/x86_64-linux-musl/bin/x86_64-linux-musl-objdump: arch/x86/lib/retpoline.o: unable to initialize decompress status for section .debug_line

I think moving musl-cross to binutils 2.32 (from the current 2.27) would fix this.

missing dynlinker names for sub-archs

for example, we currently lack dynlinker names for mipsel, mipssf, mipselsf, armeb

musl 1.1.5 is out

optionally use linux-headers package instead of full kernel source

@justincormack and me have updated sabotage's kernel-headers package.
it's now based on 3.12.6, with few minor fixes + some compatibility ifdefs for musl in libc-compat.h (which achieves roughly the same level of compatibility between kernel and userspace headers as with current glibc).
the tarball, available from
http://ftp.barfooze.de/pub/sabotage/tarballs/kernel-headers-3.12.6-3.tar.xz
http://codu.org/~rofl/tarballs/kernel-headers-3.12.6-3.tar.xz
contains the headers for all archs supported by musl and is only 750KB.

https://github.com/sabotage-linux/kernel-headers/releases/tag/v3.12.6-3

installation works via make ARCH=... prefix=... DESTDIR=... install
note that "mipsel" "microblazeel" and "armeb" are currently not supported as "ARCH". so those should either be transformed into "mips", etc or after untarring 3 symlinks created: mips->mipsel, etc.

the reason why it probably makes sense to have it optional, instead of replacing the kernel entirely is that it should be possible to fallback to the official headers when doing a port for a new arch, or when someone needs another version of the headers for some reason.