Talk:Multilib System without emul-linux Packages

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 12:24, 5 November 2024 (UTC)
:: Your reply ~~~~

GCC case

Talk status

This discussion is done as of 6 April 2015.

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 followed 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

Talk status

This discussion is done as of 7 April 2015.

eselect profile list shows a profile of the name default/linux/amd64/13.0/no-emul-linux-x86. I selected default/linux/amd64/13.0/no-emul-linux-x86/desktop/kde/systemd 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

Talk status

This discussion is still ongoing as of 6 April 2015.

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 ...

Talk status

This discussion is done as of 29 November 2016.

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 build dependencies 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)

Per the updated page change concerning "Why this article is outdated" referencing another article titled "True multilib support on amd64" with the following remote page excerpt, "However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them." The page only states to add a file globbing reference within package.use. I think the best and more formal method is the above mentioned method (eg. /etc/make.conf USE="abi_x86_32"), else users/admins will have a file globbing reference hidden within the midst of all the files listed within their package.use! As for my system having the USE="abi_x86_32" setting within it's make.conf file, seems to be doing so well, I haven't even noticed the change for the past six plus months. (Unless one is short on disk space, it's either this or adding the many 100+ individual package entries within package.use.) --Roger (talk) 18:46, 29 November 2016 (UTC)