Jump to content
funtoo forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


librin.so.1 last won the day on February 20

librin.so.1 had the most liked content!

About librin.so.1

  • Rank


  • freenode


  • Location
    Kaunas, Lithuania
  • Interests
    I program in C and such.
    I also "click heads" in games such as CSGO and the like.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. librin.so.1

    Dealing with multilib removal

    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.
  2. librin.so.1

    Dealing with multilib removal

    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.
  3. librin.so.1

    Dealing with multilib removal

    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
  4. librin.so.1

    Dealing with multilib removal

    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?