I have several amd64 gentoo systems all configured as no-multilib, but not by selecting a no-multilib profile. Instead I've copying all the settings from /usr/portage/profiles/arch/amd64/no-multilib directory into the relevant files in /etc/portage Additionally I have -multilib set in /etc/portage/package.use for sys-libs/glibc & sys-devel/gcc (although I think this is not in fact not needed as it simply duplicates what is in /usr/portage/profiles/arch/amd64/no-multilib/use.mask) I've had it this way for about 3 years, and these systems all have absolutely no 32 bit code installed whatsoever (I've confirmed, double checked on many occasions). This has never given me any insurmountable problems until today. Today, a @world update wanted to upgrade LLVM and friends from 13.0.0 to 13.0.1 but failed due to wanting me to add abi_x86_32 to sys-libs/libxcrypt & virtual/libcrypt in order to be able to proceed. FWICT this is as a result of commits 1b8078187d4d85e5f5a88f80b665051939dd48a3 (sys-libs/compiler-rt-sanitizers: Inline ABI_X86 flags to fix non-x86) and the related 70290e8454f7b834be1b8f72f3c2475e78360986 (profiles/features/multilib: enable virtual/libcrypt, sys-libs/libxcry…). I've wrestled most of today trying to work around this, but as I understand it appears to be actually impossible. My only options now are to either: a) completely re-install these systems from scratch as multilib b) uninstall the packages depending on LLVM & friends Neither of which is particularly attractive. I tried to see if I could just re-install glibc/gcc/binutils and other toolchain packages as multilib as I can live with that, but that is not possible as each requires one of the others to already be multilib. Particularly the lack of gnu/stubs-32.h in a no-multilib sys-libs/glibc is a major problem. This confirms what a Gentoo FAQ somewhere says that migration from no-multilib to multilib is not possible. I might be completely mistaken but it looks to me like this LLVM update is incompatible with no-multilib profiles? Or perhaps no-multilib sys-libs/glibc is actually unsupported and I've just been getting away with having it all this time? (although the no-multilib profile doesn't appear to me to force multilib for sys-libs/glibc) Thanks for reading!
(In reply to Eddie Chapman from comment #0) > I have several amd64 gentoo systems all configured as no-multilib, but not > by selecting a no-multilib profile. Instead I've copying all the settings > from /usr/portage/profiles/arch/amd64/no-multilib directory into the > relevant files in /etc/portage > > Additionally I have -multilib set in /etc/portage/package.use for > sys-libs/glibc & sys-devel/gcc (although I think this is not in fact not > needed as it simply duplicates what is in > /usr/portage/profiles/arch/amd64/no-multilib/use.mask) > > I've had it this way for about 3 years, and these systems all have > absolutely no 32 bit code installed whatsoever (I've confirmed, double > checked on many occasions). > > This has never given me any insurmountable problems until today. > > Today, a @world update wanted to upgrade LLVM and friends from 13.0.0 to > 13.0.1 but failed due to wanting me to add abi_x86_32 to sys-libs/libxcrypt > & virtual/libcrypt in order to be able to proceed. FWICT this is as a result > of commits 1b8078187d4d85e5f5a88f80b665051939dd48a3 > (sys-libs/compiler-rt-sanitizers: Inline ABI_X86 flags to fix non-x86) and > the related 70290e8454f7b834be1b8f72f3c2475e78360986 > (profiles/features/multilib: enable virtual/libcrypt, sys-libs/libxcry…). > This part doesn't sound right. The last part at least would only make any difference at all if you were on a multilib profile inheriting features/multilib. You've created your own no-multilib stuff. Are you sure it's all exactly matching? Because it doesn't make sense that ABI_X86_32 is even visible in that case? It should be use.masked and hence nothing can pull it in? It'd be useful to see a dump of it in /etc/portage. > I've wrestled most of today trying to work around this, but as I understand > it appears to be actually impossible. My only options now are to either: > > a) completely re-install these systems from scratch as multilib > b) uninstall the packages depending on LLVM & friends > > Neither of which is particularly attractive. > > I tried to see if I could just re-install glibc/gcc/binutils and other > toolchain packages as multilib as I can live with that, but that is not > possible as each requires one of the others to already be multilib. > Particularly the lack of gnu/stubs-32.h in a no-multilib sys-libs/glibc is a > major problem. This confirms what a Gentoo FAQ somewhere says that migration > from no-multilib to multilib is not possible. It's somewhat kind of possible now with USE=multilib-bootstrap but we don't really like people to do it if we can help it. > > I might be completely mistaken but it looks to me like this LLVM update is > incompatible with no-multilib profiles? Or perhaps no-multilib > sys-libs/glibc is actually unsupported and I've just been getting away with > having it all this time? (although the no-multilib profile doesn't appear to > me to force multilib for sys-libs/glibc) > That sounds very unlikely given that nobody noticed for the last 4 months in ~arch. > Thanks for reading! No problem! Thanks for reporting and I'm sorry for the frustration faced today. In any case, me forgetting to do 70290e8454f7b834be1b8f72f3c2475e78360986 until now has caused pain for people on multilib profiles, so my apologies there. As for solving your issue, let's try to reconcile the two statements: - you don't have any 32-bit code on your system - suddenly Portage thinks it's allowed to try satisfy 32-bit deps on things Please share: - emerge --info - the bits in /etc/portage you've copied in from the no-multilib profiles - emerge -pvO llvm clang gcc glibc sandbox libxcrypt virtual/libcrypt and we'll go from there.
Many thanks for the reply, and no need to apologise, really appreciate all the work you and others put into Gentoo :-) Actually I should have added to my original report that I first experienced the problem *without* 70290e8454f7b834be1b8f72f3c2475e78360986, as my @world update was based on an "emerge --sync" from 6AM GMT today. I then saw your commit 70290e8454f7b834be1b8f72f3c2475e78360986 and thought that might help so re-ran "emerge --sync" and confirmed your commit had been applied. Then what I believe happened (not 100% sure as since made several edits to /etc/portage) is that 70290e8454f7b834be1b8f72f3c2475e78360986 resulted in my @world update succeeding, and an update of 131 packages proceeded. Either that or I may have manually added abi_x86_32 to sys-libs/libxcrypt & virtual/libcrypt in order to get it to go. But in fact I *am* on a multilib profile, just with the settings from no-multilib manually copied. So I think that 70290e8454f7b834be1b8f72f3c2475e78360986 did have an effect for me. My profile is and has always been: default/linux/amd64/17.1/selinux But the @world update eventually failed after 65 packages (sys-libs/libxcrypt & virtual/libcrypt were updated successfully with early on) when it got to sys-libs/compiler-rt-13.0.1. That failed to build as my glibc did not have gnu/stubs-32.h - and so where I'm at right now precisely is part-way through that @world update unable to get past sys-libs/compiler-rt. The main settings as you allude are definitely in my /etc/portage/use.mask, these two: multilib abi_x86_32 But I'll add a dump of the rest of my /etc/portage in a few minutes and the other bits you requested so you have all you need. I should have added everything to start with, sorry.
Thank you! :) Just to throw in some more info: this might be some weirdness with mask vs force too, and possibly /etc/portage/$file and /etc/portage/profile/$file. So, if I just shove abi_x86_32 on my own multilib machine into /etc/portage/use.mask, that makes no difference to e.g. emerge -pvO llvm. But /etc/portage/profile/use.mask on the other hand? Works!
Created attachment 766606 [details] emerge --info output
Created attachment 766607 [details] output of: emerge -pvO llvm clang gcc glibc sandbox libxcrypt virtual/libcrypt
Created attachment 766608 [details] Contents of /etc/portage
Created attachment 766609 [details] contents of /var/db/pkg/sys-libs/glibc-2.34-r10 in case it helps
Created attachment 766610 [details] contents of /var/db/pkg/sys-libs/libxcrypt-4.4.27 in case it helps
Thanks again. Attached as requested, with a couple extra bits in case helps
(In reply to Eddie Chapman from comment #5) > Created attachment 766607 [details] > output of: emerge -pvO llvm clang gcc glibc sandbox libxcrypt > virtual/libcrypt It's interesting that you actually have multilib *on* right now for glibc: [ebuild R *] sys-libs/glibc-2.34-r10:2.2::gentoo USE="(audit) (caps) clone3 multiarch (selinux) ssp (static-libs) (-cet) -compile-locales (-crypt) (-custom-cflags) -doc -gd -headers-only (-multilib*) -multilib-bootstrap -nscd -profile -static-pie -suid -systemd -systemtap -test (-vanilla)" 0 KiB Shame that the hidden thing from make.defaults means we don't actually see the state of it in each package, but leave that alone for now. Can you try the /etc/portage/profile thing I mentioned?
Created attachment 766613 [details] output of "emerge -pvO llvm clang gcc glibc sandbox libxcrypt virtual/libcrypt" with /etc/portage/use.mask Ugh, sorry for the confusion - while I was preparing the files to attach I read your comment re. use.mask path and moved my /etc/portage/use.mask to /etc/portage/profile/use.mask, and *then* I ran the emerge -pvO, which of course does not reflect how things have been. I've always had /etc/portage/use.mask and that's where it was for the partially failed world update earlier today. So, I've just moved the file back to original location /etc/portage/use.mask and re-ran the emerge -pvO - and the output is different, attached. So this looks like it could be the problem. Let me now compare @world update with both file locations and see what happens .....
so yes, my installed glibc, which was updated to 2.34-r10 successfully in the earlier (partially failed) world update, and with /etc/portage/use.mask, has multilib. However there are no 32-bit files installed (as per CONTENTS) only 64-bit. And if I run @world update with /etc/portage/use.mask, portage wants to continue from where it failed earlier on sys-libs/compiler-rt-sanitizers due to lack of gnu/stubs-32.h in glibc. But then if I move /etc/portage/use.mask to /etc/portage/profile/use.mask and re-run the @world update it changes, it wants to rebuild several toolchain packages without multilib :-) Calculating dependencies... done! [ebuild R ] sys-apps/sandbox-2.25::gentoo ABI_X86="(64) (-32*) (-x32)" 0 KiB [ebuild R ] virtual/libcrypt-2:0/2::gentoo USE="-static-libs" ABI_X86="(64) (-32*) (-x32)" 0 KiB [ebuild R ] sys-devel/gcc-11.2.1_p20220115:11::gentoo USE="(cxx) fortran jit nls nptl openmp (pie) sanitize ssp zstd (-ada) (-cet) -custom-cflags -d -debug -doc (-fixed-point) -go -graphite -hardened (-libssp) -lto (-multilib*) -objc -objc++ -objc-gc (-pch) -pgo -systemtap -test -valgrind -vanilla -vtv" 0 KiB [ebuild R *] sys-libs/glibc-2.34-r10:2.2::gentoo USE="(audit) (caps) clone3 multiarch (selinux) ssp (static-libs) (-cet) -compile-locales (-crypt) (-custom-cflags) -doc -gd -headers-only (-multilib*) -multilib-bootstrap -nscd -profile -static-pie -suid -systemd -systemtap -test (-vanilla)" 0 KiB [ebuild R ] sys-libs/libxcrypt-4.4.27:0/1::gentoo USE="(compat) (split-usr) (system) -static-libs -test" ABI_X86="(64) (-32*) (-x32)" 0 KiB [ebuild R ] sys-libs/libomp-13.0.1::gentoo USE="(-cuda) -debug -hwloc -offload -ompt -test" ABI_X86="(64) (-32*) (-x32)" LLVM_TARGETS="AMDGPU NVPTX" 0 KiB So I'm going to let this @world update run and see if it now makes it all the way with the correct use.mask location. I'll report back.
Just to confirm, moving /etc/portage/use.mask to /etc/portage/profile/use.mask did the trick, @world update completed successfully. So no bug here, my apologies for the noise! I'm baffled as I've double checked old backups and I've definitely had the file at /etc/portage/use.mask, containing multilib and abi_x86_32, since 2018. And I'm 100% certain all that time these systems have been 64-bit only. I guess Portage was ignoring the file all along but maybe as I had -multilib in package.use for glibc & gcc that was enough to ensure no 32-bit code was built for anything. Anyway, thanks for your help.
Glad you're sorted!
