I would like to resurrect the idea of native multilib support in portage. Eradicator's original multilib tracker bug was http://bugs.gentoo.org/show_bug.cgi?id=75420. It was closed because of deficiencies in gcc and libtool for handling multilib builds. However, these issues have been since been fixed. I have patches that are loosely based on what Eradicator originally created for this bug but are forward ported to portage-2.1-r2 and refactored in several ways. I would like to re-open this bug to get the discussion going again. I build, boot, and test a multilib mips64el (o32, n32, n64) system every night. I have also built a working amd64 system (x86, amd64). This is all without the /emul hackery. Instead of cluttering this bug up too much by posting all the info here, I have a page that covers rationale, usage, code changes, the discussion up to this point, etc: http://dev.gentoo.org/~kanaka/auto-multilib/ I have included in the Cc list most of the ones that were in #75420 plus others who I know have interest. Sorry if you get this twice or didn't want to be on at all.
*** Bug 153983 has been marked as a duplicate of this bug. ***
I have finally gotten around to updating these patches incorporating many of the suggestions and bumping the underlying portage version. Briefly: - merged patches forward to portage-2.1.1-r1 and gcc-config 1.3.14 - multilib ABI dependencies - show multilib ABI info in --pretend output - pexpect regression test program to verify native multilib functionality I will be on vacation tomorrow through Dec 3rd. I wanted to get this out before I left so interested parties can play with the latest bits.
I like this idea :-O, Will be this included to portage?
*** Bug 165217 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > - multilib ABI dependencies If not slot deps (bug 174405), it seems to me that ABI dependencies should be modeled as USE deps (bug 174406).
(In reply to comment #5) > (In reply to comment #2) > > - multilib ABI dependencies > > If not slot deps (bug 174405), it seems to me that ABI dependencies should be > modeled as USE deps (bug 174406). Why? They're not either of them. They're something else. Why not introduce a dependency class covering compile options like ABI, Python .so version, whether or not static/shared is available and so on?
Bug 44132 seems to be a very similar situation to the multilib one. They have multiple mpi implementations, each with a different ABI, and they want to be able to have more than one of them installed simultaneously. We can probably use a framework that splits each ABI into a separate domain to solve both of these problems.
just FYI: solar and I have built a custom emul profile and set of scripts for building emul-linux-x86-* packages. It's not clean enough to release to the world, but any ideas not based on emul-linux-x86-*-YYYYMMDD are old and should be discarded, with the exception of emul-linux-x86-java, which has always been different from the rest.
Is this topic dead by now? I am still interested in it and I think it's a great idea. kanaka's patched portage is out of date and I'm using paludis anyway so I can't actually try it.
(In reply to comment #9) > Is this topic dead by now? No, it's just not implemented how we'd like it to be implemented yet. The current plan is to add EAPI support that is similar in some ways to what the prefix branch of portage currently offeres. However, the current prefix branch is only designed to work with a single prefix at once, while multilib involves handling multiple prefixes at once (one for each ABI).
any progress here ?
(In reply to comment #11) > any progress here ? I know that Thomas Sachau (Tommy[D]) <tommy@gentoo.org> is working on a portage patch which adds a lib32 USE flag to all packages, and uses it to control building of 32-bit libraries.
*** Bug 291034 has been marked as a duplicate of this bug. ***
This gentoo-dev mailing list thread discusses integration of the multilib overlay: http://archives.gentoo.org/gentoo-dev/msg_6420969ab583adab2c6e29c8955f96e6.xml
so over 4 Years have been past.. any progression here ? this feature would make my setup alot of cleaner. Currently i must use the dorty ABI= ARCH= emerge... trick :-(
*** Bug 381091 has been marked as a duplicate of this bug. ***
Bug URL http://dev.gentoo.org/~kanaka/auto-multilib/ is broken (HTTP 404) :(
*** Bug 383913 has been marked as a duplicate of this bug. ***
cc back amd64 if you need our support
(In reply to comment #17) > Bug URL http://dev.gentoo.org/~kanaka/auto-multilib/ is broken (HTTP 404) :( Still "available" here: http://web.archive.org/web/20090107154109/http://dev.gentoo.org/~kanaka/auto-multilib/
with the acceptance of the multilib eclasses in the tree, i think this is a dead (or at least obsolete) project now
