Re: Building a Linuxulator userland from source
- Reply: Dmitry Chagin : "Re: Building a Linuxulator userland from source"
- In reply to: Felix Palmen : "Re: Building a Linuxulator userland from source"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 05 Sep 2023 17:52:25 UTC
* 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 :( 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