i need ARCH_WRAPPER support in portage for easily handling libdir and CC settings via profile.bashrc. this blocks adding glibc-multilib. the linux32 wrapper on amd64 simply returns "i686" when running uname -m. running ebuild.sh from a wrapper allows me to use uname -m output to determine sane defaults. here is an example chunk from my profile.bashrc: [ "$(uname -m)" == "x86_64" ] && CONF_LIBDIR="${CONF_LIBDIR:=lib64}" || \ CONF_LIBDIR="${CONF_MULTILIBDIR:=lib32}" export CONF_LIBDIR export CONF_MULTILIBDIR now when i emerge zlib normally, it gets installed to lib64. if i "linux32 emerge zlib", it gets installed to lib32. another example of what i want to do with this: [ "$(uname -m)" == "i686" ] && CC="gcc32" etc, etc. amd64 isnt the only arch with a wrapper available to make things easy, so this plan of attack could be recycled and used on all multilib archs. even when not using profile.bashrc this would be useful. certain apps such as openssl and helix player wont compile 32bit at all on amd64 unless run through the wrapper.
errr... i forgot a few details in my description. heh. so if an ebuild is to be non-main bitdepth only (like glibc-multilib), it could set USE_ARCH_WRAPPER="true" in global.
i neglected to mention that linux32 is a standard tool present on all amd64 installations and is already used by catalyst to build x86 stages on amd64. sorry about the confusion.
changing to enhancement request for when work is done on a multilib portage
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Closin due to old age (pretty sure multilib stuff has been redesigned at least once since).
