Re: Building a Linuxulator userland from source

On Tue, Sep 05, 2023 at 07:52:25PM +0200, Felix Palmen wrote:
> * Felix Palmen <zirias@freebsd.org> [20230901 16:55]:
> > Posting yet another status update [...]
> 
> And the next one ;)
> 
> First, I kind of reached a "milestone", I got multimedia/makemkv to
> build with the new userland (using the ffmpeg shared libs instead of
> linking it statically as is necessary with -c7), and it *seems* to work
> just fine \o/. Unfortunately, it still segfaults in "guiserver" mode, so
> obviously this wasn't caused by the ancient userland -> still no GUI
> here for FreeBSD :(

try ktrace/kdump id, also sysctl machdep.uprintf_signal=1

> 
> But then, the bad news, it seems I'm hitting a brick wall trying to port
> gtk2 (a prerequisite for Citrix Workspace, another app I want to *try*
> to get to work). It fails building its demos, telling it can't determine
> the file type of some .png file. I assume there is some issue around
> shared-mime-info, I'm not sure yet...
> 
> But now, I have the idea to once again completely restructure my new
> userland, and I'm posting it here hoping for comments from people with
> experience regarding Linuxulator:
> 
> * So far, my linuxsrc_base metaport just pulls in what I thought to be a
>   very minimal working GNU/Linux userland: glibc, libstdc++, libgcc,
>   bash, sed, grep, awk (all the GNU flavors), openssl, coreutils, man-db
>   and a few other tools. I *think* I should also add anything to "base"
>   that's present in FreeBSD base.
> 
> * For my 'dist' ports (additional tools and libs going to /compat/linux
>   that are not part of base), I currently install them the same way as
>   the 'base' ports: PREFIX /compat/linux, but a prefix of /usr passed to
>   the respective build system. I now think I should change this to use a
>   prefix of /usr/local instead, so the libs are (hopefully) configured
>   the same way as their FreeBSD equivalents and I could drop anything
>   else (man-pages, other docs, shared data, etc) and even in most cases
>   binaries from the packages, maybe instead adding a runtime dependency
>   to the respective FreeBSD-native port. My idea is that this should
>   enable the best possible integration into the FreeBSD system, using
>   anything but the libs from ${LOCALBASE}.
> 
> So, any comments on these ideas?
> 
> Cheers, Felix
> 
> -- 
>  Felix Palmen <zirias@FreeBSD.org>     {private}   felix@palmen-it.de
>  -- ports committer --                     {web}  http://palmen-it.de
>  {pgp public key}  http://palmen-it.de/pub.txt
>  {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231