Bugzilla Bug 145737

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. ***