Jump to content
Read the Funtoo Newsletter: Summer 2023 ×

Dealing with multilib removal


Recommended Posts

So I noticed multilib support is being removed with the 1.3 release.

I personally welcome moving to pure AMD64 and have done so ages ago on most machines I manage, but then there's all that pesky proprietary software that cannot be recompiled at-will.

I've seen the wiki guide on running a x86 chroot as a workaround, but it looks like it creates a purely AMD64 system with a purely x86 system in a chroot. But I'd like to clear something out: with this particular approach, is it possible to somehow fuse the base system with whatever is in the chroot to make a makeshift multilib-like system? Reason for asking this is because in particular, some games require additional x86 software to launch / run, while the game itself outright requires AMD64  (e.g. running a AMD64-only game on steam, which itself needs x86). How about Wine, too? To quote Wine Wiki: "Even many 64-bit programs still include 32-bit components" (applicable to windows software), so being able to have a WoW64 build of wine would also be preferred, again, mostly for AMD64-only games.

If that is not possible, I suppose I could try to run a gentoo chroot within my funtoo gaming machine, but this brings a multitude of other problems, so I'd rather not, if possible. :V

TL;DR how do I run games that effectively require both x86 and AMD64 to function after upgrading Funtoo to 1.3?

Link to comment
Share on other sites

  • Funtoo Linux BDFL

First, definitely try running stuff, and report any 32-bit issues on the Funtoo bug tracker. We're working on documenting various ways to work around various strange apps but need some bugs reported first. Also, post specifics here of issues you are encountering and we'll help you out.

There are a number of approaches including chroot as you mentioned, as well as containers, and we would rather put our effort towards containers/docker solutions than continue to support legacy 32-bit multilib stuff. We want to move forward with a 'multiple roots' concept rather than treating a system as a single root.

Best,

Daniel

Link to comment
Share on other sites

What about Steam?

https://www.reddit.com/r/linux_gaming/comments/ac9f5s/any_news_of_steam_64_bit_version/

they make gnome 3 without systemd perhaps steam without multilib in 64 bit isnt impossible,

Mac has a 64 bit steam why not linux?

 

Link to comment
Share on other sites

On 1/8/2019 at 1:53 AM, drobbins said:

Our GPU-accelerated container solution should work for people in both these cases. We're currently working on it.

Just a note for the future: When removing a feature many people are relying on, it often pays of to have the replacement ready. I get the feeling that essentially disabling Steam and Wine and telling people to hold of on playing games for a couple months is going to drive many people away.

I understand that there is too much to do for too few people, and dropping features you don't feel are needed seems like a good option, but you are also serving a community of users. Telling a portion of that community that they are not wanted and should go elsewhere seems like a bad strategy, even if it frees up development time.

Personally I'm going to hold off on the 1.3 upgrade for as long as possible, and see how that turns out. 

Link to comment
Share on other sites

I did this, as i have a three hard drives, i installed Gentoo in my secondary hard drive just in case the Gpu-accelerated container go down the toilet (to give me peace of mind) , i didnt upgrade to kits 1.3 yet, if i need a new package in Funtoo i get the ebuilds from Gentoo , ebuild packge.ebuild digest and then emerge that package, if the container work well and all my games work as were working with Funtoo 1.2 i will upgrade to kits 1.3 and keep it, if not ill copy the Gentoo partition to my primary disk and get done with Funtoo, sad but thats what i would do.   

Link to comment
Share on other sites

Okay, first of all, I am sorry I did not post this earlier, even though I had this stopgap of a workaround effectively ready two weeks ago, yet I've been swamped with work. I may or may not have forgotten some minor, yet important steps as while doing it myself I encountered with a lot of strange c**p and I am not sure if my sleep-deprived self at that time memorized every bit, so if anything seems missing / out of place /simply does not work if You try this Yourself, do point out and I shall do my best to fix this post up.

Either way, as my base goal from which I can improve upon, I set out to run CSGO (is currently AMD64-only), which also needs steam to launch and run (which is currently x86-only). This would be one typical "muh games" kind of goal, which, if reached, should allow most other stuff "just work", I guess (and for me, most other stuff did work from this point on!). So I went with that.

I did achieve this goal, but it was tad a headache to figure out. My current solution is far from perfect and I shall document the main issues I am yet to solve in the end of the post. Also, if You attempt this, please make sure You read it all first and understand what is being done, why it is being done and how, as "You get to keep all the pieces if it breaks". Either way, ask if You're unsure about something. And do refer to the footnotes!

For clarification, what this """""guide""""" does is describes a way to make a makeshift multilib system where the libraries are more or less seamlessly provided to the base AMD64 system by the specially crafted chroot environment. Also, this assumes mesa. I have no desire to touch the nvidia  binary blob even with a ten meter pole, sorry.

If You attempt this and something breaks, You get to keep all the pieces if it breaks. If it so happens I take no responsibility for Your system breakage; do this at Your own risk.

I started off basing on the wiki entry on 32-bit chroot by building the chroot in /x86chroot directory. Everything in this post will assume the chroot directory to be that. Also, everything from and including the "Chroot First Steps" entries in that wiki page are irrelevant and skipped [1]. I expanded upon it with these changes:

in the OpenRC configuration part, also add these lines [2] in the start() and stop() functions, in the appropriate places (i.e. at the end of the mounting / dismounting parts of the script)

for start()

mount -o bind /var/lib/layman/ "${chroot_dir}/var/lib/layman/" >/dev/null

for stop()

umount -f "${chroot_dir}/var/lib/layman/"

Crate /lib32 and /usr/lib32 directories on the "host" and add these entries to fstab [3]:

/x86root/lib            /lib32          none    bind,nofail     0       0   
/x86root/usr/lib        /usr/lib32      none    bind,nofail     0       0

next up was to add this symlink in /lib so the x86 elf interpreter can be found where it is expected:

ld-linux.so.2 -> /lib32/ld-linux.so.2

On the host, I created a file at /etc/ld.so.conf.d/98-multilib.conf with these contents, so the x86 libraries can be located and loaded properly [4]:

/usr/lib32/gcc/i686-pc-linux-gnu/8.2.1
/usr/lib32/gcc/i686-pc-linux-gnu/7.4.1
/usr/lib32/gcc/i686-pc-linux-gnu/7.3.1
/usr/lib32/llvm/7/lib
/usr/lib32/llvm/6/lib
/usr/lib32/pulseaudio

You shall need to modify the mesa ebuild [5] for the chroot system a bit, so do set up a local overlay[6] on the chroot and make sure that the emesonargs variable have this added to it:

--libdir=lib32

For the stock mesa-18.3.1 ebuild, the easiest way to do this is to add this line as line #457.

You will need to re-emerge mesa after this if it was already emerged at that point.

Also, every time after You update/[re]build/etc. anything on the chroot, You will need to run ldconfig on the "host".

Next up, is work on the "host".  On whatever user that needs to run those icky x86 programs, You need to have these environment variable exported[7], one way or another (You can export these in Your .bashrc, for example)

LD_LIBRARY_PATH=/usr/lib:/lib:/usr/lib32:/lib32
PATH="$PATH:/x86root/usr/local/bin:/x86root/usr/bin:/x86root/bin"

Do note that the x86 paths need to go AFTER the AMD64 paths, otherwise the x86 binaries will get precedence, which is what we absolutely do not want.

At this point, lest I forgot something, You should be able to simply run those x86 programs and "muh games" as first-class-citizens on Your machine again, kinda.

KNOWN UNRESOLVED ISSUES:

For files under /usr/share/ and such, which should otherwise be arch-independent, the programs from the x86 environment are going to load ones installed for the "host". This is normally not a problem, but for some ebuilds that are only emerged on the chroot, this can pose a problem, as those files would be missing on the "host", e.g. for steam, which then fails to locate its icons and so on. One dirty solution is to copy (or symlink) the required files by hand, but this is tedious and dirty. The other solution would be to delete the said directory on the chroot and bind-mount it from the host to the chroot, sharing it. This should otherwise work fine, but, in case of man pages, there may or may not be some differences between x86 and AMD64 versions of some of them. And since You'd get the whichever arch version installed most recently, this can lead to frustrating (and hilarious?) results. I also tried working around this by playing with XDG_DATA_DIRS and other such stuff, but steam, at least, seems to ignore those like a pro.

Wine. Having a proper WoW64 wine build is non-trivial and the official ebuilds don't support that anymore, I suppose. But, with the chroot You can still do a WoW64 build manually[8] and then run it "like normal" (albeit, I'd recommend running from the build directory, i.e. without running make install). Prebuilt wine from e.g. PlayOnLinux should also run fine on this setup, in theory.

[1] The chroot is assumed to be otherwise prepared by the user with all the required libs and such for the "muh games" to run by themselves and that is otherwise not covered in this post. If You attempt this but need help configuring the x86 chroot to have all You need to run 'dem muh games, You might need another thread, but do ask either way.

[2] These are required assuming You're using steam-overlay (recommended) for installing the steam client launcher instead of trying to unpack the little sucker Yourself (not recommended).

[3] I suppose symlinks would also work, but I opted out for the bind mounts. I don't remember why.

[4] Your needs for gcc-provided lib versions may vary. I added all the ones that were available at the time; feel free to use whichever You want (and having them point to missing dirs is fine, too). The last entry with pulseaudio is required for steam as it otherwise absolutely refuses to load one specific pulseaudio lib and dies. Before You point out LD_LIBRARY_PATH, I shall note that this needs both, overall, as for some reason I am yet to figure out, some libraries absolutely need to be in ld.so.cache on thr "host" or the x86 programs are going to absolutely refuse to load them and some other libs that need their directory path to be fed through LD_LIBRARY_PATH or, again, x86 programs are going to absolutely refuse to load them. huh. *scratches head*

[5] This is needed as it appears mesa hardcodes the paths where it loads the driver libs from and in the chroot that is /lib, while on the host system that points to the AMD64 versions of the drivers (whoops!), making the x86 mesa refuse to load those and dying. I found no other way to work around this other than give it the path that is correct for the "host" system at compile time.

[6] How to set up a local overlay is out of scope for this guide. I am sure there's some wiki page about it somewhere or something.

[7] for LD_LIBRARY_PATH, please refer to [4], and for PATH, well, You need to be able to load x86 binaries, I guess *wink*.

[8] On how to build that Yourself, see Wine Wiki entry on Shared WoW64, although if You never build Wine manually yourself before, You may want to refer to several other sections of that page, too.

 

#define rant

P.S. Jesus Christ, I hate this WYSIWYG editor in this forum, how do I turn that POS off? Pretty much every single forum I ever encountered in my life allows switching to manual mode where the underlying markup, be it BB code, "markup", literal html (yes, seen that, too) or whatever is exposed directly and one can edit that comfortably. I fail to find such switch on this forum and that is making me have a baaaaaaaad time.

#undef rant

Link to comment
Share on other sites

Very nice tutorial @librin.so.1 .

Just as a alternative, if you are only interested in Steam, you can try this project https://git.nixaid.com/arno/steam. It is basically a steam inside a docker container. I tried and worked fine, the only thing that didn't work was my sound, it seems it searches for /run/pulse/native for the pulseaudio server but I don't have that path in my machine.

Link to comment
Share on other sites

  • 1 month later...

I have a few important apps that I run in wine (not Steam or games).  Before I go all in with the 1.3 upgrade, I wanted to try creating a 32-bit chroot in 1.2 to make sure I could get wine and apps working.  The problem is, I don't see any 32-bit tarballs available for 1.2 - only 64-bit.  How else might one go about this?

Link to comment
Share on other sites

5 hours ago, dkg said:

The problem is, I don't see any 32-bit tarballs available for 1.2 - only 64-bit.  How else might one go about this?

Tarballs of what? If You mean funtoo stage3 tarballs, just use a 1.3 tarball for the chroot. It's not like the chroot has to match the base  OS in version or anything.

Link to comment
Share on other sites

On 2/18/2019 at 10:16 PM, librin.so.1 said:

Tarballs of what? If You mean funtoo stage3 tarballs, just use a 1.3 tarball for the chroot. It's not like the chroot has to match the base  OS in version or anything.

Yes, I don't know why I left "stage3" out of the post.  I was not aware that they could run different versions of funtoo.  If I find time, I will give it a try this weekend.  Thanks.

Link to comment
Share on other sites

In the meantime, can anybody share experience with running apps, particularly apps in wine, using a chroot as described in the wiki?  It's not clear to me how to transparently launch applications in the chroot from a desktop (Plasma launcher/widgets).  Or whether file type associations can work.

Link to comment
Share on other sites

6 hours ago, dkg said:

Yes, I don't know why I left "stage3" out of the post.  I was not aware that they could run different versions of funtoo.  If I find time, I will give it a try this weekend.  Thanks.

Just keep in mind that with running a different funtoo version in a chroot, You need to keep the portage trees separate. So if You are following that 32-bit chroot guide from the wiki, You'd need to modify the given scripts and commands to keep /var/git/meta-repo on the host and the chroot separate. Sorry I forgot to mention this at first.

In general, though, You can not just only run a different version of funtoo, but even run Ubuntu, Arch, Fedora or whatever distro in a chroot.

Link to comment
Share on other sites

  • 3 weeks later...

No success so far.  Following the wiki instructions, when I run winecfg at the end, I get the following.  I did run the 'xhost' command.

0009:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0009:err:winediag:nodrv_CreateWindow The graphics driver is missing. Check your build!

 

Link to comment
Share on other sites

Since adding the 'X' use flag to wine-vanilla/wine-staging (not currently mentioned in guide), I can actually launch a program now.  However, I could not use a copy of the existing wine prefix, as it complained that it "is not a 64-bit installation, it cannot be used with a 32-bit wineserver."  I'd have to rebuild the prefix from scratch, not knowing all the tweaks I made to get it where it is.  With work, I could probably copy the things needed to bring it into shape.  But, it doesn't have access to any of the files from either my home folder nor NFS mounts.  I'd have to bind remount a number of things - I actually gave up remounting /home due to some issues I ran into, and concerns about sharing files between them, especially given 64-bit vs. 32-bit.  For one of my applications, I will currently load an optical disk using KDE's mounting mechanisms to '/run/media/$user/...' then have the Windows app read the disk.  I'm not seeing how to do that without a lot of hand-holding.  Also haven't figured out to launch an application without the whole tedious su/xhost/chroot/su sequence.  I also just realized that in one app, foobar2000, I use a number of features that allow me to do things like launch Konsole or Dolphin to the folder containing the music file; as-is, I could only get this to launch one of those apps within the chroot - but I would want to be using the "native" apps, not install KDE into the chroot.

In other words, so far, this looks to be a very poor substitute for multi-lib, at least where running wine is concerned, and where the goal is not to puts the apps in a chroot jail.

Link to comment
Share on other sites

  • 2 weeks later...

Im very disappointed of removing multilib without a proper solution first. i did two things : i installed Gentoo in another Drive, and with Funtoo i didnt upgrade to kits 1.3 yet, i modified a overlay so i have Mesa 19, xorg server 1.20.4, i upgaded to kernel 5.0, and i still can play whatever i want, if they dont release a solution i will delete my Funtoo install and use my home with Gentoo easy as that, i posted a question about any news about the gpu passtrough  and there was no answer if this is going to take the same time as the the new init they promised you ll have to look in another direction and say goodbye to Funtoo sad but true.

Link to comment
Share on other sites

  • 2 weeks later...

Well, since a few weeks have passed with no suggestions for my difficulties, nor news of a solution in the near term, I guess I'm faced with "downgrading" this system to Gentoo.  As much as I love Funtoo's extra features (enough that I've been a financial supporter of Funtoo for years), it just isn't providing the things I need for this system.  Hope to bring it back to Funtoo one day.

Link to comment
Share on other sites

On 3/13/2019 at 6:57 AM, dkg said:

Since adding the 'X' use flag to wine-vanilla/wine-staging (not currently mentioned in guide), I can actually launch a program now.

If You're referring to the 32-bit chroot wiki page, then indeed, it fails to mention that the host's epro profiles, flavors and mix-ins (which otherwise likely provide the "X" use flag for You) do not carry over to the chroot and thus need to be set there independently. Likewise with other portage, package and use flag settings (i.e. anything under /etc/portage). I suppose this should be fixed. I'll try to edit the page later.

If You're referring to my "guide" I posted in this thread, then yes, this information is not mentioned as it is not essential. The "guide" is purposely barebones, as it is meant as a reference and a starting point to people with enough knowledge and skill to deal with customization steps that are otherwise not inherently required for this kind of multilib setup per se. This is done in part to discourage people without insufficient skill/knowledge from even attempting all of it, seeing how it can leave the system in an unusable state done incorrectly.

On 3/13/2019 at 6:57 AM, dkg said:

However, I could not use a copy of the existing wine prefix, as it complained that it "is not a 64-bit installation, it cannot be used with a 32-bit wineserver."  I'd have to rebuild the prefix from scratch, not knowing all the tweaks I made to get it where it is.

Appears You did not make a WoW64 build of wine (I mentioned it in my "guide") and thus only got x86 wine available, so this is expected.

22 minutes ago, dkg said:

Well, since a few weeks have passed with no suggestions for my difficulties, nor news of a solution in the near term, I guess I'm faced with "downgrading" this system to Gentoo.  As much as I love Funtoo's extra features (enough that I've been a financial supporter of Funtoo for years), it just isn't providing the things I need for this system.  Hope to bring it back to Funtoo one day.

Good luck with Your Gentoo install!

BTW, I'd personally switch back to gentoo, too. But alas, my hatred towards systemd dwarfs the inconvenience of removed multilib support, so I'm staying with funtoo.

Link to comment
Share on other sites

On 4/5/2019 at 6:06 PM, librin.so.1 said:

Good luck with Your Gentoo install!

BTW, I'd personally switch back to gentoo, too. But alas, my hatred towards systemd dwarfs the inconvenience of removed multilib support, so I'm staying with funtoo.

I'm with you on the systemd issue.  But isn't Gentoo without systemd still an option?  Are you resistant to it because they support systemd at all or because you sense that they're slipping in that direction?

I never used Gentoo so I don't have an informed opinion on it. I came straight to Funtoo from Fedora/Redhat because Funtoo was one of the few distros that seemed to recognize the importance of maintaining a viable Linux ecosystem apart from systemd.

My impression from being downstream of Gentoo is that they've become less stable recently.  It was starting to feel like a trend.  Creating a new release process where stability can be maintained in spite of a much smaller developer community seems like a good step for Funtoo.  I think it could be communicated and rolled out a bit more smoothly at times, but I'm excited about the progress.

Link to comment
Share on other sites

  • Funtoo Linux BDFL

@dkg Sorry that Funtoo is not working for you but unfortunately the multilib implementation in Gentoo that 'works' for people has serious technical issues that make it hard to maintain. It is getting in the way of certain important efforts in Funtoo. We are likely going to circle back to multilib at some point but with a better implementation.

The containerization solution for steam and friends is moving forward nicely and is near-complete. Based on testing, the solution using lxd is the easiest to use. The delay has been related to getting all the NVIDIA bits properly integrated so we can do CUDA/OpenCL and NVIDIA GPU acceleration seamlessly inside containers. I am also working on GPU-accelerated docker support but I think docker is a bit more of a pain to use than lxd.

Link to comment
Share on other sites

  • 4 weeks later...
On 4/5/2019 at 3:06 PM, librin.so.1 said:

If You're referring to the 32-bit chroot wiki page, then indeed, it fails to mention that the host's epro profiles, flavors and mix-ins (which otherwise likely provide the "X" use flag for You) do not carry over to the chroot and thus need to be set there independently.

I'm aware that and X server is going to magically appear in the chroot, but I was hoping xhost would make it unnecessary, though I was pretty sure going in that it would not.

On 4/5/2019 at 3:06 PM, librin.so.1 said:

Appears You did not make a WoW64 build of wine (I mentioned it in my "guide") and thus only got x86 wine available, so this is expected.

No, I did not, as I had no need to run 64-bit Windows apps.  The point is, I could not copy the wine *prefixes* over.  This, I did not anticipate.  Not disaster, but definitely a pain.

On 4/5/2019 at 3:06 PM, librin.so.1 said:

BTW, I'd personally switch back to gentoo, too. But alas, my hatred towards systemd dwarfs the inconvenience of removed multilib support, so I'm staying with funtoo.

Gentoo still uses openrc by default.

Meanwhile, I'm still limping along with Funtoo 1.2 on that system.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...