| View previous topic :: View next topic |
| Author |
Message |
pizza-rat
Tux's lil' helper
Joined: 23 Dec 2022
Posts: 81
|
 Posted: Mon Apr 08, 2024 10:20 pm Post subject: How to revert my abi_x86_32 laziness |
 |
|
I put the abi_x86_32 USEflag in make.conf because I was lazy when installing wine/lutris.
1. is this bad?
2. what's the most painless way to remove this flag globally and set it to only the packages that need it? |
|
| Back to top |
|
 |
e8root
n00b
Joined: 09 Feb 2024
Posts: 72
|
| Posted: Tue Apr 09, 2024 4:46 am Post subject: |
|
|
Unset abi_x86_32 and run something like
to rebuild everything in one go. Maybe also add something like --jobs 4 (or however you think your system can handle, I use 16 for 64GB system and its fine because really heavy ebuilds usually run alone - do keep in mind in case you go overboard swap will be used and it unless you use zram it itsn't nice...) and --keep-going y to not need to baby-sit the emerge in case of issues.
Two packages that I know use/need abi_x86_32 are various wine versions and steam.
Steam you would need to use something like flatpak to not need 32-bit packages.
Wine if you use version 9.x you can put wow64 flag to remove need for 32-bit packages while still being able to run 32-bit Windows binaries. You apparently loose some performance through using wow64 but it is not something I could easily (read: at all) verify and really on any relatively modern computer (say built in the last decade) I would not really worry about performance of 32-bit apps, especially if it can only affect windows-linux system calls and nothing to do with 32-bit applications themselves running in Windows domain. You also cannot run 16-bit binaries with wow64 exactly like how WoW64 works on real 64-bit Windows systems.
Alternatively if you want to still use abi_x86_32 the list of packages where you absolutely need to set this USE flag will show up when you run the command.
p.s If you build app-emulation/dxvk to build your own optimized and/or latest and greatest (read -9999) version of .dll files for wine you might want to set abi_x86_32 there too otherwise you only get 64-bit dlls.
_________________
Unix Wars - Episode V: AT&T Strikes Back |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1550
|
| Posted: Tue Apr 09, 2024 5:28 am Post subject: |
|
|
If you want to keep wine, keep abi_x86_32 on wine (in package.use), remove abi_x86_32 from make.conf and try to avoid putting anything there in the future and run:
| Code: | | USE="-abi_x86_32" emerge -DUav @world |
If you want to get rid of abi_x86_32 altogether, remove abi_x86_32 on wine too (or just don't set it) and the rest is the same. However a few packages will remain because they'll always link against each other's 32bit version and you can't stop that. Come back here because you need to break the cycle and recompile them without abi_x86_32. I'll try to remember how I did it and help you but we need a few attempts.
Best Regards,
Georgi |
|
| Back to top |
|
|
e8root
n00b
Joined: 09 Feb 2024
Posts: 72
|
| Posted: Tue Apr 09, 2024 5:57 am Post subject: |
|
|
I checked it on my experimental chrooted Gentoo install with global abi_x86_32 and indeed --deep and --newuse parameters are enough. You don't need to use --emptytree
Also wine without wow64 by itself don't set abi_x86_32 flag - in this case as I understand you would completely loose support for 32-bit so either use abi_x86_32 or wow64 on wine. The wow64 USE flag is only available since wine 9.0
_________________
Unix Wars - Episode V: AT&T Strikes Back |
|
| Back to top |
|
|
pizza-rat
Tux's lil' helper
Joined: 23 Dec 2022
Posts: 81
|
| Posted: Tue Apr 09, 2024 7:30 am Post subject: |
|
|
| Hmm, seems like it would be best to remove wine/lutris first, then remove the flag, then rebuild, then try to install them again and see what's needed. This will probably take a while, so I'll save it for a day when I have the time. Will report back. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1550
|
| Posted: Tue Apr 09, 2024 7:59 am Post subject: |
|
|
| pizza-rat wrote: | | and just gradually uncomment them whenever I'm updating... |
That won't work. The only way to do it gradually is to keep abi_x86_32 on wine in package.use and rebuild that part of the world that doesn't need to be abi_x86_32 and later on deal with the remaining packages at once.
This is pretty much the choice you have because one 32bit lib depends on another and so on and you can't rebuild them gradually. At leas it won't happen naturally during regular updates.
Best Regards,
Georgi |
|
| Back to top |
|
|
pizza-rat
Tux's lil' helper
Joined: 23 Dec 2022
Posts: 81
|
| Posted: Tue Apr 09, 2024 9:17 am Post subject: |
|
|
Yeah, I edited that part of my post out after trying it and realizing it would be far more complicated  |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1550
|
| Posted: Tue Apr 09, 2024 11:03 am Post subject: |
|
|
When you come to the point to get rid of abi_x86_32 altogether, then you'll hit the circular dependency between harfbuzz and freetype. No amount of rebuilds will cause them to not link against each other and this will prevent you from getting rid of the 32bit part of them. From what I remember it was something like enabling abi_x86_32 on one and disabling it on the other until you break that cycle on the 32bit parts of them depending on each other. This is what I remember from my attempt to remove it a few years back. And then I enabled it again to play a game :-) And I haven't disabled it since. I hope wow64 gets better over time so we don't need to enable 32bit on anything ever again.
Best Regards,
Georgi |
|
| Back to top |
|
|
pizza-rat
Tux's lil' helper
Joined: 23 Dec 2022
Posts: 81
|
| Posted: Tue Apr 09, 2024 7:31 pm Post subject: |
|
|
| logrusx wrote: | | When you come to the point to get rid of abi_x86_32 altogether... I hope wow64 gets better over time so we don't need to enable 32bit on anything ever again. |
I hope so too. Some of the games I play through wine are far too temperamental for me to want to mess with trying to switch to wow64 right now  |
|
| Back to top |
|
|
e8root
n00b
Joined: 09 Feb 2024
Posts: 72
|
| Posted: Tue Apr 09, 2024 8:37 pm Post subject: |
|
|
| logrusx wrote: | This is what I remember from my attempt to remove it a few years back. And then I enabled it again to play a game  And I haven't disabled it since. I hope wow64 gets better over time so we don't need to enable 32bit on anything ever again. |
Commands I and logrusx provided should deal with abi_x86_32 all at once.
What game didn't run on wow64?
From my experience only 16-bit stuff doesn't work.
| pizza-rat wrote: | | logrusx wrote: | | When you come to the point to get rid of abi_x86_32 altogether... I hope wow64 gets better over time so we don't need to enable 32bit on anything ever again. |
I hope so too. Some of the games I play through wine are far too temperamental for me to want to mess with trying to switch to wow64 right now |
You can test how wow64 works without having to rebuild anything else than wine itself.
Also what kind of issues did running emerge -DUav @world
On my test system there is zero conflicts.
There are numerous issues when trying to remove abi_x86_32 and still keep it enabled on wine but you should be able to add abi_x86_32 after you remove it from everything. I would really do not recommend it.
On my main system with 1416 packages where I use wow64 and do not have abi_x86_32 changing wine-staging flags from wow64 to abi_x86_32 results in 142 packages needing to be rebuilt with abi_x86_32.
This is exactly the kind of BS I didn't want to deal with and why I removed 32-bit from my own system.
_________________
Unix Wars - Episode V: AT&T Strikes Back |
|
| Back to top |
|
|
pizza-rat
Tux's lil' helper
Joined: 23 Dec 2022
Posts: 81
|
| Posted: Tue Apr 09, 2024 9:37 pm Post subject: |
|
|
| e8root wrote: |
Also what kind of issues did running emerge -DUav @world
|
None, thankfully. At least when I made sure to remove wine/lutris/dxvk first. I used my usual -avuDN @world and it handled it without issue.
I'm now reinstalling wine etc. I let emerge automatically add the USEflags this time but I have a question in regards to that: why does it always try to cram the new uses into an already existing file that I've edited recently instead of just asking me to name a new one and where to save it? Instead it triggers dispatch-conf and the USEflags aren't applied. I had to run dispatch-conf afterwards, edit new config, save to a new file with nano, zap new config to get everything in order. Is it supposed to work this way? Once I even had it try to write to /etc/environment of all things. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1550
|
| Posted: Wed Apr 10, 2024 9:18 am Post subject: |
|
|
| pizza-rat wrote: | | Is it supposed to work this way? |
Yes. It uses the same mechanism that provides new configuration for the packages which needs to provide configuration to an existing file. It's more like a side effect or a happy coincidence that we can use it that way. You can go and manually rename the file in package.use or package.accept_keywords. It uses the same naming convention for the updates - they start with ._#### where # is a digit. You can directly rename it and you won't be asked to run dispatch-conf or etc-update.
When I want to redirect it in some already existing file I grep for what I want and append to the file I want it to go, then delete the update and edit the destination file manually if necessary.
I guess a bug can be filed asking for the functionality to give you choice where to write the configuration but I personally wouldn't bother the developers with it.
p.s. I didn't exactly understand you. Did you remove the 32 bit support? If so, show me the output of `emerge -pv harfbuzz freetype` because I'm pretty sure those are still 32bit enabled and they need more work because of that circular dependency which will prevent the abi_x86_32 to be disabled on either of them.
Best Regards,
Georgi |
|
| Back to top |
|
|
pizza-rat
Tux's lil' helper
Joined: 23 Dec 2022
Posts: 81
|
| Posted: Wed Apr 10, 2024 11:26 am Post subject: |
|
|
| logrusx wrote: |
I guess a bug can be filed asking for the functionality to give you choice where to write the configuration but I personally wouldn't bother the developers with it.
|
It's not a huge deal, it just felt kind of odd and unintuitive for what seems like it's meant to be a quick and easy automation.
| logrusx wrote: |
p.s. I didn't exactly understand you. Did you remove the 32 bit support?
|
Nope, I just removed the global use flag I had and didn't try to remove 32bit from anything that has it enabled by default. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21650
|
| Posted: Wed Apr 10, 2024 3:04 pm Post subject: |
|
|
| pizza-rat wrote: | | I let emerge automatically add the USEflags this time but I have a question in regards to that: why does it always try to cram the new uses into an already existing file that I've edited recently instead of just asking me to name a new one and where to save it? |
I think emerge should not do that. Rather, it should have picked the file with the name that sorts highest lexicographically, so that your new changes will override any earlier conflicting instructions in lower lexicographic names. If it is always picking the most recent file, even when that has a lower position in the sort order, that would be unexpected. Can you give a specific example of it behaving incorrectly? | pizza-rat wrote: | | Once I even had it try to write to /etc/environment of all things. |
Are you saying that emerge --autounmask-write tried to modify /etc/environment? That seems wrong. I could believe that some package update had scheduled a change to /etc/environment and that you only handled that update while trying to handle the autounmask. |
|
| Back to top |
|
|
pizza-rat
Tux's lil' helper
Joined: 23 Dec 2022
Posts: 81
|
| Posted: Wed Apr 10, 2024 8:42 pm Post subject: |
|
|
| Hu wrote: | | If it is always picking the most recent file, even when that has a lower position in the sort order, that would be unexpected. Can you give a specific example of it behaving incorrectly? |
If I'm remembering correctly, when I let it auto add USEflags for all the abi_x86_32 stuff I needed, it tried to put them all in /etc/portage/package.use/xfce4-pulseaudio-plugin or /etc/portage/package.use/xfce. I've had it try to write to 00cpu-flags before as well. For reference this is my package.use directory:
| Code: | 00cpu-flags feh krita qpdfview wine-proton
calibre firejail lutris qutebrowser wine-staging
claws gimp mc shotcut winetricks
cmus grub mpv tint2 wine-vanilla
conky gvfs opensnitch vulkan xfce
curl ibus pipewire wine xfce4-pulseaudio-plugin |
As for the /etc/environment one, yeah it's very possible I'm just misremembering here. If I see it happen again I'll make a thread. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1550
|
| Posted: Thu Apr 11, 2024 9:04 am Post subject: |
|
|
I successfully switched to wow64 but I had to rebuild wine manually to make it let go of the 32bit abi.
I don't know if wow64 will be problematic, I don't intend to run anything 32bit for now.
I didn't hit the circular dependency between harfbuzz and freetype, maybe because one of them pulled in the binary packages, so the cycle had already been broken.
A few packages are still 32bi enabled and when I failed to find out what pulled them in I realized the 32 part in:
| Code: | | [ebuild R ] dev-libs/boehm-gc-8.2.4::gentoo USE="large threads -cxx -static-libs" ABI_X86="(32) (64) (-x32)" 0 KiB |
was in brackets which meant it was profile forced so I dug up the following:
| Code: | # Michał Górny <mgorny@gentoo.org> (2023-10-06)
# Require ABIs matching MULTILIB_ABIS in gcc dependencies -- otherwise
# sys-devel/gcc[multilib] (which is forced) will fail late in build.
dev-libs/libatomic_ops abi_x86_32
dev-libs/boehm-gc abi_x86_32
...
# Michał Górny <mgorny@gentoo.org> (2017-04-08)
# Require sandbox to be multilib-capable to avoid failures when building
# multilib packages, #611292.
sys-apps/sandbox abi_x86_32
|
And the rest still insisted on abi_x86_32 for no apparent reason so I just let them be.
Now I have the following 32bit enabled packages:
| Code: | eix -I --installed-with-use abi_x86_32 --format '<installedversions:NAMEVERSION>'
dev-libs/boehm-gc-8.2.4
dev-libs/libatomic_ops-7.8.2
sys-apps/sandbox-2.38
sys-devel/clang-runtime-17.0.6
sys-libs/compiler-rt-17.0.6
sys-libs/compiler-rt-sanitizers-17.0.6
sys-libs/libomp-17.0.6
sys-libs/libxcrypt-4.4.36
virtual/libcrypt-2-r1
|
Best Regards,
Georgi |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2575
Location: Here and Away Again
|
| Posted: Thu Apr 11, 2024 9:48 pm Post subject: |
|
|
| logrusx wrote: | | I successfully switched to wow64 but I had to rebuild wine manually to make it let go of the 32bit abi. |
Could you elaborate on that a bit?
How exactly were you doing it, and what exactly was happening?
I've tested it a few times, and haven't noticed that yet.
By the by, from earlier, wouldn't
| Code: | | USE="-abi_x86_32" emerge -DUav @world |
remove it from Wine as well? :]
_________________
Kindest of regardses. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1550
|
| Posted: Fri Apr 12, 2024 7:46 am Post subject: |
|
|
| Chiitoo wrote: | | logrusx wrote: | | I successfully switched to wow64 but I had to rebuild wine manually to make it let go of the 32bit abi. |
Could you elaborate on that a bit?
How exactly were you doing it, and what exactly was happening?
I've tested it a few times, and haven't noticed that yet.
By the by, from earlier, wouldn't
| Code: | | USE="-abi_x86_32" emerge -DUav @world |
remove it from Wine as well? :] |
Well, I had to run the same command but for win-staging explicitly because full world update just didn't want to disable abi_x86_32 on it. Maybe it was default on in the ebuild, I don't know, it didn't pass through my mind to investigate further.
EDIT: even if it was default on in the ebuild, that should not have prevented dropping it when USE="-abi+x86_32" was on the command line.
Best Regards,
Georgi |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2575
Location: Here and Away Again
|
| Posted: Fri Apr 12, 2024 5:20 pm Post subject: |
|
|
| logrusx wrote: | | Chiitoo wrote: | | logrusx wrote: | | I successfully switched to wow64 but I had to rebuild wine manually to make it let go of the 32bit abi. |
Could you elaborate on that a bit?
How exactly were you doing it, and what exactly was happening?
I've tested it a few times, and haven't noticed that yet.
By the by, from earlier, wouldn't
| Code: | | USE="-abi_x86_32" emerge -DUav @world |
remove it from Wine as well? :] |
Well, I had to run the same command but for win-staging explicitly because full world update just didn't want to disable abi_x86_32 on it. Maybe it was default on in the ebuild, I don't know, it didn't pass through my mind to investigate further.
EDIT: even if it was default on in the ebuild, that should not have prevented dropping it when USE="-abi+x86_32" was on the command line.
Best Regards,
Georgi |
Yeah, the command-line would, or at least should prevail there. I don't think we force it anywhere either.
If you see it happen again, do let us know!
As a general note on the new-style 'wow64' in Wine, some Wine developers still consider it having "crippled 3D support" [1], so it will not work for everything, but for some things, it indeed does.
1. https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/message/K4AKMFXJ27KHE6LMVLWXV5QU5UBXDENV/
_________________
Kindest of regardses. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1550
|
| Posted: Fri Apr 12, 2024 6:11 pm Post subject: |
|
|
Fortunately I have that buffer still in memory.
After several attempts I decided to let that go: https://bpa.st/G5JA and continue later;
It completed with: https://bpa.st/AZ7A
Another try at full world update didn't report anything for update;
Then I did that: https://bpa.st/ODFA and here I realized I had two slots of wine emerged;
Here I finally realized I had abi_x86_32 for xz-utils in a separate file for some reason, so I got rid of it, although that should not have had a role in it;
So I cleaned up 9:0, finished with preserved libraries, I'm posting the output because of them: https://bpa.st/EZDA
Then I finally run this and let it go: https://bpa.st/EXKA It finished without preserved libraries;
And here I decided to make my life harder in case I decide to play another time-wasting game and finally removed wine: https://bpa.st/IABA
What I realized just now, pasting the output is I had two slots of wine-mono, but I don't think this should have caused it either.
Then I forcefully rebuilt some more packages with 32bit abi disabled and then I let the few ones portage wanted to enable 32bit abi on get rebuilt with it but I think this is already irrelevant.
Best Regards,
Georgi |
|
| Back to top |
|
|
|
Portage & Programming
