| 1 |
Zac Medico schrieb: |
| 2 |
> Thomas Sachau wrote: |
| 3 |
>> Hi together, |
| 4 |
>> |
| 5 |
>> as announced in a previous mail, i created a fork of portage, which has support to create 32bit libs |
| 6 |
>> during compile phase for 64bit platforms (currently amd64 tested, ppc64 untested). |
| 7 |
>> |
| 8 |
>> In short, it does execute every src_* phase twice with keeping a workdir for every ABI and saving |
| 9 |
>> some default environment vars (like *FLAGS). Since the current ABI is the last one in this order, |
| 10 |
>> the 64bit phase will overwrite everthing from 32bit phase except those parts, which have a different |
| 11 |
>> install location, so mostly libs, which go in lib32 instead of lib64. |
| 12 |
>> |
| 13 |
>> A current ebuild and docs for using it are currently in the portage-multilib branch of the multilib |
| 14 |
>> overlay. |
| 15 |
>> |
| 16 |
>> I asked zmedico about inclusion into the main svn tree of portage, but he requested a council ok |
| 17 |
>> before he would be accepting it. So this is my request for discussion and ok (in tomorrows or the |
| 18 |
>> following meeting) from the council. |
| 19 |
> |
| 20 |
> An important thing to note is that there are necessary changes to |
| 21 |
> emul-* ebuilds that are technically an EAPI change, since they won't |
| 22 |
> work with old package managers that don't have support for lib32 USE |
| 23 |
> flags. |
| 24 |
|
| 25 |
I currently have emul-* ebuilds in my branch, which use lib32 usedeps, but ebuilds could instead |
| 26 |
just use something like "|| ( emul-linux-qtlibs qt-core[lib32] )". So this part should be no |
| 27 |
drawback for actually adding multilib support to main tree portage. |
| 28 |
|
| 29 |
-- |
| 30 |
Thomas Sachau |
| 31 |
|
| 32 |
Gentoo Linux Developer |
Archives