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!

Currently adding more symlinks for the very same dynamic linker (aka #ELF "program interpreter") to my linux-glibc port, making sure it's present in /lib, /lib64, /usr/lib and /usr/lib64 -- yes, different #Linux (and #GNU) tools expect it in different places 🤯

Mood ... dafuq is this crap...

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 🙄