I'd like to be able to turn o32 support completely off, allowing n32+n64 multilib without o32. Right now, multilib on mips is always o32 + n32 and/or n64, but always o32. I've preemptively added some multilib subprofiles to this effect.
USE flags are not the way i'm trying to take things with multilib. if o32 is not in MULTILIB_ABIS, then it should not be built.
Sounds good. I was just working on catalyst today and thinking about how weird having both MULTILIB_ABIS="..." and USE="$abi" was.
Actually, it seems that removing o32 from MULTILIB_ABIS already does the trick. Looking at toolchain.eclass, it looks like all we should do for mips is wipe out the n32/n64 USE flags and fix the following snipped to select the default ABI from MULTILIB_ABIS or DEFAULT_ABI. use n64 && mips_abi="--with-abi=64" use n32 && mips_abi="--with-abi=n32" Right?
Created attachment 276824 [details, diff] patch to remove n32/n64 USE flags from toolchain.eclass The attached patch removes the n32/n64 USE flags from toolchain.eclass, and by extension, gcc. It uses the DEFAULT_ABI variable to select what to pass to gcc as the argument to --with-abi=. The only problem is that gcc seems to want to bootstrap itself using -mabi=32, which for a profile with MULTILIB_ABIS="n64 n32" (without o32) fails. How can we fix this?
Joseph Myers says there's not really a way to configure only n32/n64 ABIs without o32. So, I think unless someone knows a quick way to hack around it, we should commit the toolchain.eclass patch to get rid of the n32 and n64 USE flags and shelve the rest until upstream gcc works this out. For my future self: removing o32 from MULTILIB_ABIS works fine for glibc already. It's gcc that fails to build then.
patch looks fine to me. i'd poke Kumba about it, and if he doesnt care, feel free to commit.
Committed. Marking as Resolved/Upstream while we wait for gcc to allow us to select which ABIs we want in multilib.
