A Linuxulator userland built from source

[zirias@]

As I already mentioned it in other threads, I decided to add some summary about my current "research/poc" project here: I'm trying to build a Linuxulator userland directly from source. This might be an alternative to the current practice of re-packaging (and adjusting) an existing Linux distribution to get the Linuxulator userland, as is done by the linux-c7 ports. It might also turn out to be not feasible.

My current work in progress is here in the form of a ports overlay: https://github.com/Zirias/freebsd-ports-overlay-linuxsrc
You can just clone that repository and add it as an overlay to poudriere in order to test it.

I'll give my intermediate assessment of this approach:

The good:

• So far, it works. A userland created that way is very likely to "just work" on FreeBSD, because everything will be built with a GNU toolchain (binutils, gcc, glibc) configured for exactly the Linux kernel version the respective FreeBSD kernel claims syscall compatibility with (currently Linux 4.4 for FreeBSD 13.2 and Linux 5.15 for FreeBSD 14.0).
• It's easily possible to provide the newest versions of the toolchain and important shared libs independent from some Linux distribution. Things like paths can be configured at build time (making adjustments to work well on FreeBSD simpler) and some parts of existing FreeBSD ports for some shared libs can be reused for the corresponding "Linuxulator port".

The bad:

• This approach comes with the risk to create "yet another Linux distribution". Although all you need to support Linux applications is typically shared libs, they come with their own build dependencies. Case in point, my overlay already contains IIRC around 150 ports, just to have a userland that provides the ffmpeg libs and gtk2 (in somewhat complete configurations). I'm currently hitting kind of a roadblock adding gtk3 support, because this requires librsvg, which in turn requires rust (need a compiler targeting Linux) to build the latest versions. Building/packaging rust is cumbersome. One thing is perfectly clear, I would never be able to maintain all of this alone.
• Several (ugly) hacks/workarounds for issues with both the existing ports framework and poudriere are currently needed, you can find them in linuxsrc.mk. This is not surprising, building software targeting Linux was never a supported use case. These issues should be solved in a better way....

The "ugly" (unclear so far):

• Whether the approach of building from source is good or bad for application compatibility must be evaluated. On the one hand, offering the latest versions of important (widely used) shared libs has the potential to improve compatibility. On the other hand, this userland will be different from any existing Linux distribution, so applications specifically targeting e.g. a "RedHat" system might suffer.

So, that's it. Maybe someone on here is interested to have a look, maybe even help, if so, please contact me with comments/patches/...

 

[IThoughtTooLongForThis]

Does audio work?
If not, what needs to be done as I have no idea how audio works under the Linux-c7 packages because audio doesn’t work in a Linux jail.

I’m having issues with outdated libraries with ut99 469c - appears to be relating to audio on Linux-c7 (outdated libs - libstdc++) and my Linux jail (can’t find the audio device).

 

[shkhln]

I’m having issues with outdated libraries with ut99 469c - appears to be relating to audio on Linux-c7 (outdated libs - libstdc++) and my Linux jail (can’t find the audio device).

You should probably make another thread about the game. Anyway, OldUnreal-UTPatch469d-Linux-amd64 works with the default linux-c7 environment using an alternative Cluster audio backend. Set AudioDevice=Cluster.ClusterAudioSubsystem in ~/.utpg/System/UnrealTournament.ini.

 

[zirias@]

Yes, this is off-topic in this thread, it seems to be an issue with some individual (and, in this case, very old) Linux application.

Please also understand that the Linuxulator userland (in /compat/linux by default) is not a jail. You can (more-or-less) easily create Linux jails as you wish yourself, they're isolated anyways, while the Linuxulator userland is meant to integrate with the host FreeBSD system and is therefore much more flexible, but also requires more thought and work.

Currently waiting for someone to create a lang/linuxsrc-rust port for me ? – I guess this strategy won't work out though ... ?

 

[IThoughtTooLongForThis]

Yes, this is off-topic in this thread, it seems to be an issue with some individual (and, in this case, very old) Linux application.

Please also understand that the Linuxulator userland (in /compat/linux by default) is not a jail. You can (more-or-less) easily create Linux jails as you wish yourself, they're isolated anyways, while the Linuxulator userland is meant to integrate with the host FreeBSD system and is therefore much more flexible, but also requires more thought and work.

Currently waiting for someone to create a lang/linuxsrc-rust port for me ? – I guess this strategy won't work out though ... ?

I’m sorry. I was perhaps a bit too verbose. I should have just asked if audio works within your Linuxulator project.

 

[zirias@]

I’m sorry. I was perhaps a bit too verbose. I should have just asked if audio works within your Linuxulator project.

FreeBSD's native audio interface is OSS/USS via /dev/dsp, this will work independently from Linuxulator, interacting with the device is just the same. For other APIs on top of that (like ALSA, pulse, portaudio, jack, whatever), Linux libraries might be necessary and it's just a question of adding the corresponding "linuxsrc-" ports. AFAIR, I already have libasound (for ALSA) included...