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

@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!

@meka @bdiederik