Finally, my #Linux-native #GNU toolchain for #FreeBSD's #Linuxulator works for C and C++ on #aarch64, #amd64 and #i386 ๐Ÿฅณ

I guess that's a good time to actually announce the ongoing project!
https://lists.freebsd.org/archives/freebsd-ports/2023-August/004263.html

Building a Linuxulator userland from source

And now, we have a working #Linux #bash running in #FreeBSD's #linuxulator

Which also finally makes the "ldd" script installed by #glibc work ๐Ÿ˜Ž

Ok, enough for today ๐Ÿ˜‰

https://github.com/Zirias/zfbsd-ports/blob/linux/shells/linux-bash/Makefile

zfbsd-ports/shells/linux-bash/Makefile at linux ยท Zirias/zfbsd-ports

Zirias' FreeBSD ports tree. Contribute to Zirias/zfbsd-ports development by creating an account on GitHub.

GitHub

Today's progress: #GNU #coreutils and glibc's localedata seem to work fine in #FreeBSD's #Linuxulator, in addition to bash.

Still, coreutils is not complete yet, it *should* use hash functions from #OpenSSL, so, time to port that for #Linux (tomorrow).

Today's achievement: We now have #OpenSSL (and #GNU coreutils built using it), plus grep, sed, awk, make, groff *and* man-db in #FreeBSD's #Linuxulator userland.

But there's a catch ๐Ÿ˜ž It doesn't build with #poudriere any more. Can be patched, and I guess I should soon look into getting this fixed... (**edit**: See answer, somewhat working without a patch now!)

For details, see here:
https://lists.freebsd.org/archives/freebsd-ports/2023-August/004286.html

HEADS-UP: poudriere needs patching (was: Building a Linuxulator userland from source)

Good news, I found a workaround without patching poudriere, my branch is updated!

poudriere-testport will probably fail, but poudriere-bulk works this way.

For the next iteration, support #Linux 5.15 on #FreeBSD versions supporting it ... doing this full rebuild again to test. ๐Ÿฅฑ

In case anyone tried and wondered why the branch is currently broken ๐Ÿ™ˆ

I'm working on adding a new USES for this #Linuxulator userland. It should hide all the "crap" needed to build it, and also help with creating new ports, either *for* it (e.g. shared libs), or just using it.

So I have to rework each and every port now, including test builds...

Right now, I'm test-building "native" gcc ... for the third time ๐Ÿ˜‚ so, native toolchain almost complete again.

I hope to get the branch into sane shape tomorrow!

#Linux #FreeBSD #Linuxulator

Userland built from source for #FreeBSD's #Linuxulator is making progress again (and yes, my branch builds and works again!)

โ˜‘๏ธ Metaports "linuxsrc_base" for a minimal base userland and "linuxsrc-devtools" for minimal basic tools needed to build #Linux software (just C and C++ and some common tools)
โ˜‘๏ธ Automatic selection of the Linux kernel version based on target FreeBSD version, overridable in DEFAULT_VERSIONS (but checked for compatibility of course)
โ˜‘๏ธ A new "USES=linuxsrc" to do all the ugly "plumbing" needed for building Linux software using FreeBSD #ports, offering different configurations.

Guess now I could start adding some optional packages and try to get some *real* Linux application working ๐Ÿ˜Ž

https://github.com/Zirias/zfbsd-ports/blob/linux/Mk/Uses/linuxsrc.mk

zfbsd-ports/Mk/Uses/linuxsrc.mk at linux ยท Zirias/zfbsd-ports

Zirias' FreeBSD ports tree. Contribute to Zirias/zfbsd-ports development by creating an account on GitHub.

GitHub

Spent this day (besides work, hehe) simplifying a few ports and hunting down a few bugs and now, it all builds fine on all supported target systems (#FreeBSD {13.2,14.0}/{aarch64,amd64,i386}). Yay.

So, just tried to create a *very* first port in "dist" mode (installed to Linuxulator prefix, but not part of the "base" system).

Well, I guess the "interesting" issues just begin ๐Ÿ™ˆ
https://lists.freebsd.org/archives/freebsd-current/2023-August/004433.html

Possible issue with linux xattr support?

Hitting the next roadblock in my #FreeBSD #Linuxulator "userland from source" project: #Linux #Python is causing trouble. I got it to build and package, but runtime paths are wrong, *somehow* the "/compat/linux" prefix "sneaks in" ๐Ÿ˜ž (still didn't understand how exactly...).

You might ask why port python at all, and indeed, I didn't plan to do so initially.

The issue is build systems. With the goal to port shared libraries that might be needed by (closed-source) Linux binaries, not all of them use plain #make (or #GNU #autotools) for building.

#cmake is popular, so I'll need it. To build it using shared libraries itself, one of its prerequisites needs #meson, which, in turn, requires python. ๐Ÿคฏ

Ahh, welcome to dependency hell ๐Ÿ˜œ

Python issue solved the "redneck repair" way, installing *everything* to /usr/lib64 (on a 64bit system) instead of *just* the architecture-dependent stuff. Now, python works and finds all its modules... ๐Ÿ™„

After porting lots of extra python tools (cause #pip won't do it for proper packaging with staging), it seems I finally have a working #meson in my #FreeBSD #Linuxulator userland ๐Ÿฅณ

Nevermind all these extra modules install to /usr/lib. Well, it works, I don't care ๐Ÿ˜‚

Doing a full rebuild of all the #Linux ports now just to be sure (cause I also changed stuff in my USES). If all is fine, branch will be updated ๐Ÿ™

Watching it all come together ... looking good so far ๐Ÿ™