#linuxulator — Public Fediverse posts

🎩✨ Oh look, someone discovered the #Linuxulator on #FreeBSD and thinks it's magical because VS Code kinda works. 🎉🚀 It’s like finding out that water is wet—astoundingly groundbreaking! 🧙‍♂️🔍
https://hayzam.com/blog/02-linuxulator-is-awesome/ #VSCode #discovery #techmagic #groundbreaking #HackerNews #ngated

🎩✨ Oh look, someone discovered the #Linuxulator on #FreeBSD and thinks it's magical because VS Code kinda works. 🎉🚀 It’s like finding out that water is wet—astoundingly groundbreaking! 🧙‍♂️🔍
https://hayzam.com/blog/02-linuxulator-is-awesome/ #VSCode #discovery #techmagic #groundbreaking #HackerNews #ngated

🎩✨ Oh look, someone discovered the #Linuxulator on #FreeBSD and thinks it's magical because VS Code kinda works. 🎉🚀 It’s like finding out that water is wet—astoundingly groundbreaking! 🧙‍♂️🔍
https://hayzam.com/blog/02-linuxulator-is-awesome/ #VSCode #discovery #techmagic #groundbreaking #HackerNews #ngated

🎩✨ Oh look, someone discovered the #Linuxulator on #FreeBSD and thinks it's magical because VS Code kinda works. 🎉🚀 It’s like finding out that water is wet—astoundingly groundbreaking! 🧙‍♂️🔍
https://hayzam.com/blog/02-linuxulator-is-awesome/ #VSCode #discovery #techmagic #groundbreaking #HackerNews #ngated

@trashheap <https://www.reddit.com/r/freebsd/comments/1qyh3pe/comment/o43qttr/>

"… Maybe first runs of www/chromium are just a little fragile. …"

I made a messy screen recording that shows failure with a first run.

Cc @clf

#FreeBSD #DRM #Widevine #Chromium #Linuxulator

Update on my #FreeBSD #Linuxulator "userland from source" project: Fixing "interesting" issues 🙄

I meanwhile created a #ports #overlay, for easy testing in different environments, and trying it on my "productive" builder, there were suddenly lots of failures. The "weirdest" one now took me many days to fully understand: For some ports, "stage" seemed to install the files just fine, yet "package" didn't find any files. 🤯

Turns out installing using #Linux tools created the stagedir below /compat/linux instead. Trying to understand why, the answer was "because it could".

The indirect reason was #ccache, forcing #poudriere to do everything as root by default, and for root, /compat/linux is writable. There are still some other fails, maybe also ccache-related, but at least I just committed a workaround (including a warning) for *this* issue:
https://github.com/Zirias/freebsd-ports-overlay-linuxsrc/commit/e354a4d999e79f40d0f6aee1a40c897613ec7460

Did all these tests, did some fixes, "#Linuxulator userland from source" branch builds fine on #FreeBSD 14-CURRENT/13.2-RELEASE, aarch64/amd64/i386 🥳

Now doing test builds with 15-CURRENT, which already has a fix for the #Linux #xattr issue. Unfortunately, it's still incomplete. Neverending story 😞

JFTR, not blaming dchagin at all. It seems Linux has some very weird design decisions, and semantics of the xattr syscall return codes -- EPERM is considered fatal by GNU/Linux tools, because Linux returns ENOATTR or ENOTSUP when access to e.g. the system namespace is restricted 🤯

Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳

Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!

They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).

Ok, no #scons yet, didn't need it so far 🙈

Time for cleanup after identifying two "interesting" issues:

1.) #FreeBSD ports come with a Templates/config.site file which is normally used by #GNU #autoconf, containing quite a lot of "cache variables" so autoconf can avoid running the actual tests. Nice, but completely wrong when targeting #Linux. So, add an empty "CONFIG_SITE=" variable to every linux port, and suddenly I can also remove some explicit cache variables again 🙈

2.) I'm building the "native" toolchain for #Linuxulator --with-sysroot=/compat/linux, which makes sure the linker reliably finds startup files and system libs, without stuff from FreeBSD base interfering. BUT: This completely breaks when some explicit lib path to /usr/lib or /usr/lib64 is added (and many build systems will do that), because sysroot doesn't apply here. Therefore, add wrapper scripts around gcc and g++ filtering out any "-L/usr/lib" or "-L/usr/lib64" argument 🙈 with that, Linux #bash builds without any patches! 🥳

Now, waiting for builds.

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!

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 🙈