Building a #Linuxulator userland from source on #FreeBSD -- I'm not giving up yet. But, starting over ๐
This time, I try building some "complete" #GNU cross-toolchain targeting #Linux first in some dedicated prefix. Maybe this will finally work out. ๐
Progress again. 
GCC builds fine when I previously install binutils in the exactly *same* prefix!
Ok, this means I'll need an extra "bootstrapping" port for binutils as well...
Time for bed!
Been a week now I'm working on this idea ...
So far, whenever something looked like good progress, I ran into some dead end one or two ports later.
Should probably decide for some #timebox I will set myself for this. If I can't at least come up with a *working* cross (#FreeBSD -> #Linux) #GNU toolchain within that timebox, the idea should be abandoned as unfeasible ๐
I'm carefully optimistic now again ๐
After first building very basic/limited "-bootstrap" versions of binutils and gcc into a separate prefix, it seems I could finally build a complete #GNU cross (#FreeBSD -> #Linux) toolchain, including #binutils, #glibc and #gcc (with libstdc++). This final cross gcc at least passed the most basic sanity check -- it successfully compiles an empty program ๐
Now doing a bit of cleanup and then trying whether this beast is able to build the *real* (native) glibc for a new #Linuxulator userland ๐
And we're getting closer ... this new cross-toolchain successfully builds a "native" glibc as the first package for the new #Linuxulator userland ๐ฅณ
So now, just a few more ports until I reach one that will require C++11 threading functionality ... that's where it finally broke beyond repair with my first more naive approach (without any "bootstrapping" ports/packages).
Ok. #zstd was the first #Linux port that needs C++11 threads. And, it builds!
My #GNU cross toolchain on #FreeBSD finally seems to work! ๐ฅณ
Time to party, hehe. Or, time for bed in fact.
Next step will be a *native* Linux toolchain to build the rest of the #Linuxulator userland.
https://github.com/Zirias/zfbsd-ports/blob/linux/archivers/linux-zstd/Makefile
This feature-branch finally starts to look somewhat promising, just added native #Linux #GNU #binutils for #FreeBSD's #Linuxulator ๐
linux_base-dirs is a tiny metaport just owning ${LINUXBASE} and a few essential subdirs.
Everything prefixed "lxcross-" is part of the cross-toolchain and installed to ${LXCROSSBASE}, defaulting to ${LOCALBASE}/linux-cross.
Everything suffixed "-bootstrap" is some minimal/temporary port needed to build the full cross-toolchain and installed to ${LXBOOTSTRAP}, defaulting to ${LXCROSSBASE}/bootstrap.
Everything prefixed "linux-" is Linux-native and installed to ${LINUXBASE}.
linuxheaders44 just contains the headers from Linux-4.4.x, installed to ${LINUXBASE} but coming with a slave-port installing to ${LXCROSSBASE} for the cross toolchain.
Next step: GNU gmp! Let's see ๐
We have #glibc, #zlib, #binutils, #gmp, #mpfr and #mpc ... in theory everything needed to build a full-featured native #gcc for C and C++. Oh wow. Now, trying to create *this* port ๐
Edit: My hope is that with the --sysroot option (set to ${LINUXBASE}), this new toolchain will only ever look for libraries inside ${LINUXBASE}, avoiding weird build issues you might get when using the existing linux-c7-devtools port. Well, I'm not sure I fully understand this --sysroot magic ๐
Another little update on this endeavor .. native #Linux #GCC for #FreeBSD's #Linuxulator finally builds! ๐ฅณ
Still needs some "love" in detail (like, correct path for man files).
And also, I have to find a way to package #libgcc separately, cause most software built for Linux using GCC will need it, and it doesn't make sense that everything pulls in the whole GCC as a dependency ...
Well, maybe tomorrow then ๐
Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) ๐ฅณ
So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!
He, finally. The #Linux-native #GNU toolchain for #FreeBSD's #Linuxulator just passed a first sanity check using C++ ๐ฅณ
I guess this means I could start creating ports for a basic userland now... ๐
Trying to get this to the other archs supported by #FreeBSD's #Linuxulator (amd64 and i386), I'm hitting yet another wall: #Linux headers fail to build there. Oh freakin hell, I expected to do quite some adaptions to support all 3 archs, but I didn't expect it to fail at *this* stage ๐คฏ
Already tried to understand what happens in Linux' build system. Well, it's not exactly easy to understand ๐
Shot in the dark, trying it with #gcc (instead of the base #clang) now... (which will take a while cause my test machine has to *build* this gcc first, bah ....)
Well ... no, building with #gcc didn't help.
Turns out the issue were #ELF relocation types. I have no idea why #Linux needs them *just* to build the headers (which is all I need for #Linuxulator, cause the actual #kernel will *still* be #FreeBSD), but yep, one type is named slightly differently: R_X86_64_JUMP_SLOT on Linux, R_X86_64_JMP_SLOT on FreeBSD. It has the same value, 7, so for now I just hardcoded it in the port Makefile for the Linux headers. ๐ (hey, it works ๐คทโโ๏ธ)
@thindil No, that's not the issue, it was really just about this slightly different spelled constant for some ELF relocation type ... it works now.
I'm btw only testing on 14 so far. But I use #Linux 4.4.x for the headers (to be compatible with FreeBSD 13). I will add a metaport later that will pick Linux 5.10(?) on 14 instead.
For the #GNU toolchain, I'm using the newest versions in any case. They're still compatible with Linux 4.4 ๐
@thindil Thanks!
I'm almost done with at least the cross (#FreeBSD -> #Linux) #GNU toolchain for all supported archs (aarch64. amd64 and i386), currently working on #glibc for it. It's a bit tedious work because all parts of the toolchain seem to have a pkg-plist dependent on the target architecture ๐
@thindil That's what I assume as well, once I'm done with the toolchain, architecture-specific differences should be rare (if encountered at all). ๐
Just finished the cross-version of #glibc for all archs. Two more (#binutils and #gcc) to go for the FULL cross-toolchain. That will be the goal for today, the native toolchain maybe tomorrow ๐
@thindil it sure does. Another one of these things that *should* be solved once the *native* toolchain is completed.
Just redefine ${STRIP_CMD} (for direct usage), and when used from "install -s", it should then automatically use the "native" strip, because the toolchain is compiled with --with-sysroot=${LINUXBASE} ... we will see!
@bdiederik No. #Debian's #kfreebsd is a #GNU userland configured to use the (native) #FreeBSD kernel. What I'm building here is a #GNU userland using a #Linux kernel (although "faked" by #FreeBSD's #Linuxulator -- the kernel can provide a Linux-compatible userspace-ABI, syscalls etc...)
The goal is to replace the ancient "linux-c7" userland currently offered in FreeBSD ports. I'm testing here whether building a userland from source would be a feasible way ๐
@meka @bdiederik Right now, all I have is a working native toolchain. On aarch64. Next step, test on i386 and amd64 (to cover all archs supported by #FreeBSD's #Linuxulator at all) and do the necessary adaptions.
Once *this* is done, I can try to start building an *actual* Linuxulator userland from source.
I'm certainly not talking about documentation at this stage ๐
But thanks, nice to see people are interested in this project. If it works out at all (still not sure), I *am* sure I won't be able to maintain it all alone ๐
@zirias A more functional and easy to use #Linuxulator would be awesome!
@hnygd @meka @bdiederik The "normal" approach would be to find another (newer) Linux distribution and re-package *that* instead of Centos-7.
And maybe, this is the better approach, I'm not sure yet. But I really want to try the "build it all from source" approach as well ๐
Felix Palmen ๐ฏ
Bartek Jasicki
Bram Diederik aka daft_dutch
meka
Stephan Lichtenauer | ื ื ืกืชื