Jump to content
funtoo forums

librin.so.1

Members
  • Content Count

    2
  • Joined

  • Last visited

  • Days Won

    1

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

librin.so.1 had the most liked content!

About librin.so.1

  • Rank
    Newbie

Online

  • freenode
    librin

Personal

  • 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

201 profile views
  1. [6] · In email notifications about new replies to threads, opening the "Go to this post:" link always gives me the same error message: Sorry, there is a problem We could not locate the item you are trying to view. Error code: 2S136/C
  2. This forum has several issues that together make it seem like it is semi-broken. (Although, I can see how #2 through #5 could be intentional, but I really hope they're not.) [1] · My user (and apparently, a few of others) are stuck at zero post count for some reason. EDIT: making my sixth? (not sure; didn't count) post now gave me a post count of one. What the... [2] · The post writing interface appears to lack a switch to disable the WYSIWYG mode and go to plain-text mode which allows to manipulate the whichever underlying markup language directly. I consider this very much a bug. [3] · Posts within a thread lack post numbers (i.e. numbers showing which post it chronologically is in a given thread.) This makes referencing a post in larger threads tad nontrivial if wanting to avoid outright quoting the said post. [4] · "Newlines are on sale – buy one, get one free!" i.e. adding an explicit newline in the text produces double line spacing AKA "reddit spacing", which is not always desired, yet some way to avoid this, when needed, is not exposed. Solving #2 would indirectly solve this one, I suppose. [5] · There is no way to either inline "code" or explicitly switch to a fixed-width font for a part of text, either witch are used to denote e.g. a command being referenced, which would be rather useful knowing the context of this forum. This too be would likely be indirectly solved if #2 gets solved.
  3. 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. 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. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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?
×
×
  • Create New...