About cross-compilers and their use - Programming On Unix

Users browsing this thread: 1 Guest(s)
z3bra
Grey Hair Nixers
I've recently started building my very own linux distribution, and on the process I had to deal with cross-compilers. My experience with them was close to zero. I only had to deal with mingw once, but it was under arch and all I had to do was install a bunch of packages, and use whatever tool I was asked to to get get application compiled for windows.

This time, it was different, I had to setup a cross-compiler to compile applications for the same OS and even the same architecture.
Why would I do that you ask? For the libc. I decided to compile all my packages against musl instead of glibc. This can be done without a cross-compiler, but setting up one definitely makes things easier.

I then learnt how to make my own cross-compiler from scratch, using gcc and musl. This was quite a hard process, but I had some good resources to figure out how to do it. Ypnose also helped me a lot with it!

Now that I found how to build, use and automate it, I've been wondering. Does anyone else have experience with cross-compilers? What did you use them for, and how did you build them?
BANGARANG, MOTHERFUCKER
Houseoftea
Long time nixers
No expirence at all with them, though I do remember someone getting a little fiesty on irc because their cross compiling was not working ;)

If you don't mind, when you have something presentable could I test out your distro?
Also tell me more about it I'm really curious

Also can you write a little about musl?
There's that suckless distro that uses it, and I think alpine and void as well?
Is there a reason to using it or is it a preference thing
z3bra
Grey Hair Nixers
I'm far from having something presentable right now. I still have a lot of things to package first, trouble shoot it, and make a bootable image (or at least, a container).

First of all, this is not MY distro, I'm working with dcat on it, but for now we're both experimenting here and there before working together on the same goal. It will be statically linked against musl, installable in under a minute (so easy to bootsrap) and will focus on minimalism and simplicity, both for the maintenance and the tools.

musl is s standard C library, like newlib, glibc or dietlibc. Simply put, it's what provides "stdio.h" and friends, as well as printf(), open(), malloc(), ... You get it.
The most used libc in glibc (the GNU monster). It's huge, and contains a lot of bugs (because of its size). It also tries to implement more features than necessary, which could lead to more bugs.
musl libc is simpler, stronger and smaller. So it's a good candidate for stability and security. You're right, alpine linux use it, and void has a musl-based image (not the default one).

So yeah, using musl is a preference, as glibc is free too.
xero
Long time nixers
>musl is stronger

i'm very interested in this topic. please keep us apprised
cjm
Long time nixers
I am also very intrigued. I love OS development and anything to do with a better libc and new OS makes me happy :-P. Keep us updated Z3bra
z3bra
Grey Hair Nixers
I think musl is stronger than glibc because it tries to follow POSIX standards more quickly, and make standard function more secure.
By keeping everything simpler, they make the code easier to review/maintain, so the libc is much stronger overall. Now that's just my POV and some would probably disagree. I don't care much about them.

So what have I done so far?

I have a cross compiler installed in $HOME/cross/gcc-x86_64:

Code:
$ sponge < /home/egull/cross/gcc-x86_64/README
TRIPLET :       x86_64-linux-musl
PREFIX  :       /home/egull/cross/gcc-x86_64
GCC     :       4.8.5
BINUTILS:       2.25
MUSL    :       1.1.10
KERNEL  :       4.1.4

$ tree /home/egull/cross/gcc-x86_64/bin/
/home/egull/cross/gcc-x86_64/bin/
├── x86_64-linux-musl-addr2line
├── x86_64-linux-musl-ar
├── x86_64-linux-musl-as
├── x86_64-linux-musl-c++filt
├── x86_64-linux-musl-cpp
├── x86_64-linux-musl-elfedit
├── x86_64-linux-musl-gcc
├── x86_64-linux-musl-gcc-4.8.5
├── x86_64-linux-musl-gcc-ar
├── x86_64-linux-musl-gcc-nm
├── x86_64-linux-musl-gcc-ranlib
├── x86_64-linux-musl-gcov
├── x86_64-linux-musl-gprof
├── x86_64-linux-musl-ld
├── x86_64-linux-musl-ld.bfd
├── x86_64-linux-musl-nm
├── x86_64-linux-musl-objcopy
├── x86_64-linux-musl-objdump
├── x86_64-linux-musl-pkg-config
├── x86_64-linux-musl-ranlib
├── x86_64-linux-musl-readelf
├── x86_64-linux-musl-size
├── x86_64-linux-musl-strings
└── x86_64-linux-musl-strip

0 directories, 24 files

It links everything statically, and use only what's in $HOME/cross/gcc-x86_64/bin/x86_64-linux-musl/{lib,include}
So if I want to compile something against, let's say libressl, I first need to install libressl's headers and libs to my toolchain's root.

I have written a dumb package manager which can install packages to whatever root the $PMROOT variable points to. It makes everything stupidly easy to work with
Here is what happens when compiling curl alone, with --with-ssl flag:

Code:
$ (cd tree/curl; pmkit build)
[...]
configure: WARNING: SSL disabled, you will not be able to use HTTPS, FTPS, NTLM and more.
[...]

$ work/curl-7.42.1/bin/curl --version
curl 7.42.1 (x86_64-unknown-linux-gnu) libcurl/7.42.1
Protocols: ftp gopher http
Features: Largefile UnixSocket

SSL is disabled as the configure script couldn't find the appropriate libs.
Now if I build libressl, and install it to the cross-compiler directory:

Code:
# useless output is suppressed here
$ (cd tree/libressl; pmkit build)
$ PMROOT=$HOME/cross/gcc-x86_64/x86_64-linux-musl; export PMROOT
$ pmkit add repo/libressl\:2.1.6.pkg
$ pmkit list
libressl 2.1.6
$ (cd tree/curl; pmkit build)
$ work/curl/bin/curl --version
curl 7.42.1 (x86_64-unknown-linux-gnu) libcurl/7.42.1 LibreSSL/2.0.0
Protocols: ftp ftps gopher http https
Features: Largefile NTLM NTLM_WB SSL UnixSockets

SSL support is now compiled in, yay!
I can then just remove the libressl package from the cross environment:

Code:
$ PMROOT=$HOME/cross/gcc-x86_64/x86_64-linux-musl; export PMROOT
$ pmkit del libressl
$ pmkit list
$

Next step is to figure out what are the base packages that are needed on a fresh install. If you have any suggestion, they're welcome!
z3bra
Grey Hair Nixers
I'm finally confident with my package building system, so now I'll start packaging more and more to finally bootstrap a working system. You can find the package recipes here: http://git.z3bra.org/cgit.cgi/ports. I'll keep you updated when it will be in a "bootable" state
I should look into musl. Nice work!