Jump to content


  • Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Great Post
    seaofash reacted to mortenlj in Dealing with multilib removal   
    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. 
  2. Great Post
    seaofash reacted to librin.so.1 in 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?
  3. Great Post
    seaofash reacted to librin.so.1 in 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.
    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. Great Post
    seaofash reacted to cafaia in How to unmask clang, llvm, lldb 4 or 5?   
    Hello, seaofash!
    You can do this to use lldb in sys-devel/llvm-3.9.1-r1:
    # mkdir -p /etc/portage/profile/use.mask # echo '-lldb' > /etc/portage/profile/use.mask/test-forum # USE="lldb" emerge -1 =sys-devel/llvm-3.9.1-r1 or # echo '=sys-devel/llvm-3.9.1-r1 lldb' > /etc/portage/package.use/test-forum But if you want llvm, lldb and clang in version 4, you need all this:
    # mkdir -p /var/git/overlay/local/sys-devel/llvm # cd /var/git/overlay/local/sys-devel/llvm/ # wget https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-devel/llvm/llvm-4.0.1.ebuild # ebuild llvm-4.0.1.ebuild digest # mkdir -p /var/git/overlay/local/sys-devel/llvm-common # cd /var/git/overlay/local/sys-devel/llvm-common/ # wget https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-devel/llvm-common/llvm-common-4.0.1.ebuild # ebuild llvm-common-4.0.1.ebuild digest And the file /etc/portage/package.unmask/test-forum with this: sys-devel/clang:4 sys-devel/llvm:4 =dev-util/lldb-4.0.1 =sys-devel/llvm-common-4.0.1 =sys-devel/clang-runtime-4.0.1  
  5. Trolling
    seaofash reacted to cafaia in Can't emerge 'www-client/chromium-62.0.3202.18::net-kit'   
    To compile this version of chromium you have upgrade gcc-5.3.0-r1 to gcc-5.4.0. Look here: https://bugs.funtoo.org/browse/FL-4235. sys-devel/gcc-5.4.0 is sufficient to complile this version of chromium.
  6. Trolling
    seaofash reacted to Oleg Vinichenko in Different boost versions conflict   
    i believe the 2.3.8-r8 portage version supposed to fix this. please, update.
  7. Trolling
    seaofash reacted to Oleg Vinichenko in Trouble updating after migration to meta-repo   
  • Create New...