Talk:Multilib System without emul-linux Packages

GCC case
Whatever was meant in the sections "GNU Compiler Collection special case" and "Dead END" should be rephrased in an understandable and spellchecked way. I am guessing that gcc will pull additional libraries if USE=gcj is enabled and that those are not working with the 32bit approach yet. Mark (talk) 22:19, 03 October 2014.


 * I just folled this guide and had no problems so far. Luttztfz (talk) 00:41, 15 January 2015 (UTC)


 * I tend to agree with Mark. I'm left guessing as to what is meant, even though I know how to program in C.  Guess I'll figure-out myself after things break further.  What a huge mess not having "app-emulation/emul-linux-x86-baselibs app-emulation/emul-linux-x86-db app-emulation/emul-linux-x86-gtklibs app-emulation/emu -linux-x86-medialibs app-emulation/emul-linux-x86-opengl app-emulation/emul-linux-x86-qtlibs app-emulation/emul-linux-x86-soundlibs app-emulation/emul-linux-x86-xlibs" packages!  I would say it's much easier having these few packages, versus mucking around creating a mess of custom settings and custom USE profiles for abi_x86_32 just to have a default install on a 64 bit platform. No choice now as those packages are now masked. One hundred and two packages need to be specifying with "abi_x86_32" USE flag! --Roger (talk) 23:51, 5 April 2015 (UTC)


 * As I sit here and gnaw at this issue for a little while, since emerge Portage is already automatically finding which packages require "abi_x86_32" USE flag, users should only need to be required to specify "abi_x86_32" globally, and only the packages needing 32 bit compatibility should be built. This was mentioned within the article, but looks like globally stating this is frowned upon as it inadvertently pulls other packages as well?  Something doesn't sound right here, and likely only stating "abi_x86_32" (globally) within the users' make.conf file should be sufficient.  Likely this is the future plan, if not already. --Roger (talk) 00:13, 6 April 2015 (UTC)

no-emul-linux-x86 profile
shows a profile of the name. I selected  and followed this guide. My ACCEPT_KEYWORDS="amd64" hence stable and not testing. Selected packages are "~amd64". Everything looks good.

Shouldn't the profile be mentioned in the guide?

Luttztfz (talk) 00:40, 15 January 2015 (UTC); updated Luttztfz (talk) 00:51, 15 January 2015 (UTC)

All profiles are now no-emul-linux-x86 by default. So, "no-emul-linux-x86" were all removed. Just make "emerge --sync" and read eselect news about upgrade to true multilib. You don't need to read anything else. This article is outdated. --Diamond (talk) 17:16, April 6, 2015


 * Thanks for the tip concerning "eselect news". The "eselect news" article concerning this Multilib issue was dated 2015-03-28 Górny.  Here's a link to that specific news article, http://www.gentoo.org/support/news-items/2015-03-28-true-multilib.html  (So, I did do the correct thing, ignoring manually listing the depends on the emul packages and just going with what Portage stated as needing abi_x86_32 USE Flag!)  --Roger (talk) 17:33, 7 April 2015 (UTC)


 * Makes me wonder if this page should just be deleted and replaced with this specific eselect news article. --Roger (talk) 17:35, 7 April 2015 (UTC)

Seriously need an update
This article should be reworked now that emul-linux-x86-* are masked for removal and abi_x86_* are enabled for all --Grknight (talk) 22:01, 6 April 2015 (UTC)

So tired of adding abi_x86_32 entries to /etc/portage/package.use ...
I'm so tired of adding abi_x86_32 entries to /etc/portage/package.use on my x86_64 platform, I must currently have about 40+ (or more) abi_x86_32 package entries to the package.use file so far. I am currently in the process of just adding the abi_x86_32 USE flag to the global variables. (ie. /etc/make.conf USE="abi_x86_32")

Although this modification now pulls in many more packages then required for some 32 binaries, this will be obviously lessen the confusion surrounding required 32 bit builds for many 32 bit binaries. (ie. Steam proprietary binaries usually do not automatically pull in 32 bit depends, and some configuration files may require 32 bit builds such as asoundrc.) This modification will also likely enlargen the /lib32 folder to around 1 Gigabyte instead of ~3.2 Megabytes. ---Roger (talk) 00:26, 27 April 2016 (UTC)