|Summary:||Native Portage Multilib Support|
|Product:||Portage Development||Reporter:||Joel Martin (RETIRED) <kanaka>|
|Component:||Conceptual/Abstract Ideas||Assignee:||Portage team <dev-portage>|
|Severity:||enhancement||CC:||alexander, asturm, binki, blubb, bugs+gentoo, chutzpah, cryos, darkbasic, dberkholz, denilsonsa, drwook, duncanphilipnorman, eradicator, esigra, ferringb, filipe, fling, geekypenguin, gentoo-bugzilla, gentoo, gent_bz, geoman, gfa, idl0r, jaak, jlec, jrmalaq, kevquinn, kingtaco, kripton, kugelfang, lanius, lisa, lu_zero, m.debruijne, mads, main.haarp, maltee, maze, mips, mmk, nichoj, nikoli, nolan, nunomilheiro, pacho, pageexec, patrakov, polynomial-c, ppc64, res, roberto.castagnola, russ, schleinzer, sparc, spiderx, spock, sven.koehler, tacvbo, thedude0001, thothonegan, toolchain, verynotbad, voyageur, WineLauncher.Jonathan, wolf31o2, ysharma|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||306835|
|Bug Blocks:||155723, 217094, 162625, 303431, 312471, 347820|
Description Joel Martin (RETIRED) 2006-08-31 11:27:46 UTC
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.
Comment 1 Alec Warner 2006-11-03 18:03:51 UTC
*** Bug 153983 has been marked as a duplicate of this bug. ***
Comment 2 Joel Martin (RETIRED) 2006-11-18 18:47:33 UTC
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.
Comment 3 Pacho Ramos 2007-01-30 20:16:19 UTC
I like this idea :-O, Will be this included to portage?
Comment 4 Jakub Moc (RETIRED) 2007-02-05 06:25:11 UTC
*** Bug 165217 has been marked as a duplicate of this bug. ***
Comment 5 Zac Medico 2007-05-02 23:25:18 UTC
(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).
Comment 6 Ciaran McCreesh 2007-05-02 23:34:54 UTC
(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?
Comment 7 Zac Medico 2007-05-08 18:35:23 UTC
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.
Comment 8 Mike Doty (RETIRED) 2008-02-26 21:53:46 UTC
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.
Comment 9 Malte E. 2008-05-19 17:08:50 UTC
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.
Comment 10 Zac Medico 2008-05-19 19:18:31 UTC
(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).
Comment 11 Eric Grüttefien 2009-08-06 08:07:16 UTC
any progress here ?
Comment 12 Zac Medico 2009-08-06 08:23:38 UTC
(In reply to comment #11) > any progress here ? I know that Thomas Sachau (Tommy[D]) <firstname.lastname@example.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.
Comment 13 Gilles Dartiguelongue 2009-10-30 00:41:07 UTC
*** Bug 291034 has been marked as a duplicate of this bug. ***
Comment 14 Zac Medico 2010-03-06 00:41:07 UTC
This gentoo-dev mailing list thread discusses integration of the multilib overlay: http://archives.gentoo.org/gentoo-dev/msg_6420969ab583adab2c6e29c8955f96e6.xml
Comment 15 Eric Grüttefien 2011-01-30 18:52:51 UTC
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 :-(
Comment 16 Lars Wendler (Polynomial-C) (RETIRED) 2011-08-29 21:55:13 UTC
*** Bug 381091 has been marked as a duplicate of this bug. ***
Comment 17 Jaak Ristioja 2011-08-30 05:19:36 UTC
Bug URL http://dev.gentoo.org/~kanaka/auto-multilib/ is broken (HTTP 404) :(
Comment 18 SpanKY 2011-09-25 19:45:21 UTC
*** Bug 383913 has been marked as a duplicate of this bug. ***
Comment 19 Agostino Sarubbo 2012-02-01 13:04:32 UTC
cc back amd64 if you need our support
Comment 20 jannis 2012-10-16 08:43:48 UTC
(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/
Comment 21 SpanKY 2015-08-21 21:20:22 UTC
with the acceptance of the multilib eclasses in the tree, i think this is a dead (or at least obsolete) project now