[gentoo-dev] MULTI_ABI support addition to main tree portage

[gentoo-dev] MULTI_ABI support addition to main tree portage

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 3241 bytes --]

Hi,

i have already written about this some months ago and updated the code in relation to the comments
especially from vapier.

Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others (setup_abi_env function
in bin/auto-multilib.sh contains the full list), then does build the package as usual. If additional
ABIs are requested, it checks after src_install, if there are possible ABI-specific files (libs,
headers or, if requested for every ABI, also binaries). If those are found, the image dir is moved
away and a new run is started, where again at start abic-specific vars are set and then the complete
src* phases are run. Once all requested ABIs are done, the image dirs are merged into the final
image dir. The following pkg_* phases are each running for every ABI.
Currently, only different libs and headers are installed by default, binaries will be the ones from
the default ABI, unless you tell portage to install binaries for all requested ABIs, in which case a
wrapper will select the ABI-specific binary depending on the environment.
The current implementation uses a USE-dep like way internally to satisfy the needed dependencies, so
that e.g. 32bit libs on a 64bit platform get their required dependencies built with 32bit libs
installed. For the rare case, where the crosscompile does fail and there is only a need for the
binary and no linking against the libs, i have also a var, which disables this auto-dependency
calculation for specified packages.

For the user interface, portage shows a USE_EXPANDed var, which contains the avaidable ABIs, as an
example for "emerge -pv media-libs/jpeg":

[ebuild   R   ] media-libs/jpeg-8b  USE="-static-libs" MULTILIB_ABI="amd64 x86"

Those ABIs can be handled like USE flags, in this case, they are "multilib_abi_amd64" and
"multilib_abi_x86", so you can use those USE flags to enable/disable specific possible ABIs either
globally or per package.

The basic implementation can be used without changing main tree ebuilds or eclasses, but e.g. for
the replacement of emul-* libs, this will require EAPI-support for ABI-specific USE-deps for
binary-only packages or packages like wine.

I would first like to see, if there are any bigger concerns especially with the implementation and
how it is supposed to work.

If there are no such concerns or if they have been resolved, i would like to request some help for
the documentation and PMS-patch related work.

For install instructions, please have a look at [1], the code can be found in the multilib branch of
portage git repo at [2].

While i did not yet get to the implementation of it, i would also like to propose something similiar
for languages (like python, ruby or others), so that the basic parts are inside the PM and we can
drop the different ways of implementation and allow users a much more fine-grained control on a per
package base (in relation to the current way python eclass based very complex implementation works).

[1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc
[2]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib

-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Fabian Groffen]

Hi Thomas,

On 01-12-2010 19:57:46 +0100, Thomas Sachau wrote:
> The current implementation uses a USE-dep like way internally to
> satisfy the needed dependencies, so that e.g. 32bit libs on a 64bit
> platform get their required dependencies built with 32bit libs
> installed.

This just means that if I install package X, which depends on Y and
MULTILIB_ABI="amd64 x86", Portage will complain (or reinstall) Y if it
doesn't have both amd64 and x86, right?

> While i did not yet get to the implementation of it, i would also like
> to propose something similiar for languages (like python, ruby or
> others), so that the basic parts are inside the PM and we can drop the
> different ways of implementation and allow users a much more
> fine-grained control on a per package base (in relation to the current
> way python eclass based very complex implementation works).

This would be absolutely great!


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

Am 01.12.2010 20:05, schrieb Fabian Groffen:
> Hi Thomas,
> 
> On 01-12-2010 19:57:46 +0100, Thomas Sachau wrote:
>> The current implementation uses a USE-dep like way internally to
>> satisfy the needed dependencies, so that e.g. 32bit libs on a 64bit
>> platform get their required dependencies built with 32bit libs
>> installed.
> 
> This just means that if I install package X, which depends on Y and
> MULTILIB_ABI="amd64 x86", Portage will complain (or reinstall) Y if it
> doesn't have both amd64 and x86, right?

Right.

-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Alexey Shvetsov]

Well =)

This will be killer feature in gentoo =P
Also what about more complex arhes than ia32? like mips of ppc?

PS also with this feature seems amd64 and x86 can be merged in one
arch (like it was done in kernel) since its only abis of ia32

2010/12/1 Thomas Sachau <tommy@gentoo.org>:
> Hi,
>
> i have already written about this some months ago and updated the code in relation to the comments
> especially from vapier.
>
> Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others (setup_abi_env function
> in bin/auto-multilib.sh contains the full list), then does build the package as usual. If additional
> ABIs are requested, it checks after src_install, if there are possible ABI-specific files (libs,
> headers or, if requested for every ABI, also binaries). If those are found, the image dir is moved
> away and a new run is started, where again at start abic-specific vars are set and then the complete
> src* phases are run. Once all requested ABIs are done, the image dirs are merged into the final
> image dir. The following pkg_* phases are each running for every ABI.
> Currently, only different libs and headers are installed by default, binaries will be the ones from
> the default ABI, unless you tell portage to install binaries for all requested ABIs, in which case a
> wrapper will select the ABI-specific binary depending on the environment.
> The current implementation uses a USE-dep like way internally to satisfy the needed dependencies, so
> that e.g. 32bit libs on a 64bit platform get their required dependencies built with 32bit libs
> installed. For the rare case, where the crosscompile does fail and there is only a need for the
> binary and no linking against the libs, i have also a var, which disables this auto-dependency
> calculation for specified packages.
>
> For the user interface, portage shows a USE_EXPANDed var, which contains the avaidable ABIs, as an
> example for "emerge -pv media-libs/jpeg":
>
> [ebuild   R   ] media-libs/jpeg-8b  USE="-static-libs" MULTILIB_ABI="amd64 x86"
>
> Those ABIs can be handled like USE flags, in this case, they are "multilib_abi_amd64" and
> "multilib_abi_x86", so you can use those USE flags to enable/disable specific possible ABIs either
> globally or per package.
>
> The basic implementation can be used without changing main tree ebuilds or eclasses, but e.g. for
> the replacement of emul-* libs, this will require EAPI-support for ABI-specific USE-deps for
> binary-only packages or packages like wine.
>
> I would first like to see, if there are any bigger concerns especially with the implementation and
> how it is supposed to work.
>
> If there are no such concerns or if they have been resolved, i would like to request some help for
> the documentation and PMS-patch related work.
>
> For install instructions, please have a look at [1], the code can be found in the multilib branch of
> portage git repo at [2].
>
> While i did not yet get to the implementation of it, i would also like to propose something similiar
> for languages (like python, ruby or others), so that the basic parts are inside the PM and we can
> drop the different ways of implementation and allow users a much more fine-grained control on a per
> package base (in relation to the current way python eclass based very complex implementation works).
>
> [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc
> [2]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib
>
> --
> Thomas Sachau
>
> Gentoo Linux Developer
>
>



-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

Am 01.12.2010 20:11, schrieb Alexey Shvetsov:
> Well =)
> 
> This will be killer feature in gentoo =P
> Also what about more complex arhes than ia32? like mips of ppc?

I cant speak in detail about the other arches, since i dont know them that much. Basicly, if you can
crosscompile for a different arch/abi (so either the target arch/abi binaries run on your arch or
none are executed/needed for that), then this should be possible for them too. The code itself is
not limiting it (unless i missed some location), so you should be able to test this with an adjusted
custom or additionally sourced profile.

-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

[gentoo-dev] Re: MULTI_ABI support addition to main tree portage

[Diego Elio Pettenò]

Il giorno mer, 01/12/2010 alle 22.11 +0300, Alexey Shvetsov ha scritto:
> 
> PS also with this feature seems amd64 and x86 can be merged in one
> arch (like it was done in kernel) since its only abis of ia32
> 
I would suggest against that.

For the kernel it's somewhat easier, but for userland, x86 and amd64 are
definitely far enough that I wouldn't be surprised if it'll take a few
more years before we can easily consider the two keywords a single one.

Just think of a relatively-common situation.

void *bar = foo();

with foo implicitly declared. On 32-bit userland it'll be "all fine",
but will crash badly on 64-bit userland.

And this is without adding to the necessity of PIC, and the rest of
little details that this brings with it.

For the sake of safety, let's _not_ merge this, as we have said too many
times for me to dig up.


And finally, let's not call it ia32. No matter what Intel wants it to be
called, if you were to call it like that, you'd just have a number of
people asking why their ia64 stage don't work.

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/

Re: [gentoo-dev] Re: MULTI_ABI support addition to main tree portage

[Alexey Shvetsov]

Well ok =)

i call it ia32 since its original name of this arch however it can be
better called x86 (x86_32 and x86_64)

PS seems many users were confused with ia64 since they associate it
with core2 and nahalem

2010/12/1 Diego Elio Pettenò <flameeyes@gmail.com>:
> Il giorno mer, 01/12/2010 alle 22.11 +0300, Alexey Shvetsov ha scritto:
>>
>> PS also with this feature seems amd64 and x86 can be merged in one
>> arch (like it was done in kernel) since its only abis of ia32
>>
> I would suggest against that.
>
> For the kernel it's somewhat easier, but for userland, x86 and amd64 are
> definitely far enough that I wouldn't be surprised if it'll take a few
> more years before we can easily consider the two keywords a single one.
>
> Just think of a relatively-common situation.
>
> void *bar = foo();
>
> with foo implicitly declared. On 32-bit userland it'll be "all fine",
> but will crash badly on 64-bit userland.
>
> And this is without adding to the necessity of PIC, and the rest of
> little details that this brings with it.
>
> For the sake of safety, let's _not_ merge this, as we have said too many
> times for me to dig up.
>
>
> And finally, let's not call it ia32. No matter what Intel wants it to be
> called, if you were to call it like that, you'd just have a number of
> people asking why their ia64 stage don't work.
>
> --
> Diego Elio Pettenò — “Flameeyes”
> http://blog.flameeyes.eu/
>
> If you found a .asc file in this mail and know not what it is,
> it's a GnuPG digital signature: http://www.gnupg.org/
>
>
>



-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

[gentoo-dev] Re: Re: MULTI_ABI support addition to main tree portage

[Diego Elio Pettenò]

Il giorno gio, 02/12/2010 alle 00.44 +0300, Alexey Shvetsov ha scritto:
> 
> i call it ia32 since its original name of this arch however it can be
> better called x86 (x86_32 and x86_64)

It is by far not the original name of the architecture… it was retconned
after IA-64 was released. And it only covers x86, not x86-64/amd64
(which Intel called IA32e or EM64T iirc).

FWIW the kernel calls it i386.

> PS seems many users were confused with ia64 since they associate it
> with core2 and nahalem
> 
Both of which have nothing to do with IA64. Given that users don't seem
to grasp the difference between architectures, why considering merging
two architectures that are, simply speaking, different (in userland,
that is)?

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/

Re: [gentoo-dev] Re: Re: MULTI_ABI support addition to main tree portage

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On Wed, 01 Dec 2010 22:47:45 +0100
Diego Elio Pettenò <flameeyes@gmail.com> wrote:

> x86-64/amd64 (which Intel called IA32e or EM64T iirc).

I think I've seen them calling it 'Intel 64' too which introduces even
more confusion.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3572 bytes --]

El mié, 01-12-2010 a las 19:57 +0100, Thomas Sachau escribió:
> Hi,
> 
> i have already written about this some months ago and updated the code in relation to the comments
> especially from vapier.
> 
> Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others (setup_abi_env function
> in bin/auto-multilib.sh contains the full list), then does build the package as usual. If additional
> ABIs are requested, it checks after src_install, if there are possible ABI-specific files (libs,
> headers or, if requested for every ABI, also binaries). If those are found, the image dir is moved
> away and a new run is started, where again at start abic-specific vars are set and then the complete
> src* phases are run. Once all requested ABIs are done, the image dirs are merged into the final
> image dir. The following pkg_* phases are each running for every ABI.
> Currently, only different libs and headers are installed by default, binaries will be the ones from
> the default ABI, unless you tell portage to install binaries for all requested ABIs, in which case a
> wrapper will select the ABI-specific binary depending on the environment.
> The current implementation uses a USE-dep like way internally to satisfy the needed dependencies, so
> that e.g. 32bit libs on a 64bit platform get their required dependencies built with 32bit libs
> installed. For the rare case, where the crosscompile does fail and there is only a need for the
> binary and no linking against the libs, i have also a var, which disables this auto-dependency
> calculation for specified packages.
> 
> For the user interface, portage shows a USE_EXPANDed var, which contains the avaidable ABIs, as an
> example for "emerge -pv media-libs/jpeg":
> 
> [ebuild   R   ] media-libs/jpeg-8b  USE="-static-libs" MULTILIB_ABI="amd64 x86"
> 
> Those ABIs can be handled like USE flags, in this case, they are "multilib_abi_amd64" and
> "multilib_abi_x86", so you can use those USE flags to enable/disable specific possible ABIs either
> globally or per package.
> 
> The basic implementation can be used without changing main tree ebuilds or eclasses, but e.g. for
> the replacement of emul-* libs, this will require EAPI-support for ABI-specific USE-deps for
> binary-only packages or packages like wine.
> 
> I would first like to see, if there are any bigger concerns especially with the implementation and
> how it is supposed to work.
> 
> If there are no such concerns or if they have been resolved, i would like to request some help for
> the documentation and PMS-patch related work.
> 
> For install instructions, please have a look at [1], the code can be found in the multilib branch of
> portage git repo at [2].
> 
> While i did not yet get to the implementation of it, i would also like to propose something similiar
> for languages (like python, ruby or others), so that the basic parts are inside the PM and we can
> drop the different ways of implementation and allow users a much more fine-grained control on a per
> package base (in relation to the current way python eclass based very complex implementation works).
> 
> [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc
> [2]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib
> 


Nice to see progress on this, it's a headache to have to make emul
packages grow forever when any application (usually wine) requires
it :-S, and this would allow much more flexibility

Thanks a lot :-D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[justin]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Hi,

after testing this, and I have to say it mostly works smooth and fine, I
hit a huge problem.

I wanted to emerge a package which just depends on glibc provided libs
for the oposite ABI my main ABI is. This specific package has an
optional support for python which would require to have a second python
installation, so I disabled it. Nevertheless the package inherits the
python.eclass which DEPENDS on eselect-python, which DEPENDS on python.
Resulting in the need of a two ABI python installation although I don't
want python support.

To solve this there are two options:

1. Eclasses shouldn't be allowed to depend unconditionally on packages.
In case of python where there is PYTHON_DEPEND="python? X" it should be
doable.
2. USE dependend inherit of eclasses


justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[justin]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On 15/12/10 12:06, justin wrote:
> Hi,
> 
> after testing this, and I have to say it mostly works smooth and fine, I
> hit a huge problem.
> 
> I wanted to emerge a package which just depends on glibc provided libs
> for the oposite ABI my main ABI is. This specific package has an
> optional support for python which would require to have a second python
> installation, so I disabled it. Nevertheless the package inherits the
> python.eclass which DEPENDS on eselect-python, which DEPENDS on python.
> Resulting in the need of a two ABI python installation although I don't
> want python support.
> 
> To solve this there are two options:
> 
> 1. Eclasses shouldn't be allowed to depend unconditionally on packages.
> In case of python where there is PYTHON_DEPEND="python? X" it should be
> doable.
> 2. USE dependend inherit of eclasses
> 
> 
> justin
> 

Please ignore this, I found somewhere deeply buried in a DEP the python
dependency. It wasn't from the eclass

Sorry for the noise.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Zac Medico]

On 06/02/2011 03:04 PM, Matt Turner wrote:
> For this problem, I think some kind of per-ebuild ABI_DEPENDENT flag
> should be used to recognize which packages ABI dependencies should
> apply to. Without thinking about it too hard, it seems like perhaps
> only packages in RDEPEND should be considered for ABI USE
> dependencies.

We can express it with either of the existing PROPERTIES or RESTRICT
variables. This way, we don't need to add a whole new variable every
time that we decide to add a boolean flag like this.
-- 
Thanks,
Zac

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Matt Turner]

On Thu, Jun 2, 2011 at 9:00 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 06/02/2011 03:04 PM, Matt Turner wrote:
>> For this problem, I think some kind of per-ebuild ABI_DEPENDENT flag
>> should be used to recognize which packages ABI dependencies should
>> apply to. Without thinking about it too hard, it seems like perhaps
>> only packages in RDEPEND should be considered for ABI USE
>> dependencies.
>
> We can express it with either of the existing PROPERTIES or RESTRICT
> variables. This way, we don't need to add a whole new variable every
> time that we decide to add a boolean flag like this.
> --
> Thanks,
> Zac

Hi Zac,
Thanks for the response.

Have you looked at Tommy[D]'s work? What do you think needs to happen
for it to be merged?

Thanks,
Matt

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Zac Medico]

On 06/05/2011 04:44 PM, Matt Turner wrote:
> Have you looked at Tommy[D]'s work? What do you think needs to happen
> for it to be merged?

I haven't looked at the code in detail, but the idea behind it seems
reasonable. Given the complexity of the issue, I think that it needs to
be approved as a GLEP before it's merged in mainline portage. The GLEP
should thoroughly discuss a migration plan that makes the migration
process as smooth as possible for our users and our ebuild developers alike.
-- 
Thanks,
Zac

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]

El mié, 01-12-2010 a las 19:57 +0100, Thomas Sachau escribió:
> Hi,
> 
> i have already written about this some months ago and updated the code in relation to the comments
> especially from vapier.
> 
> Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others (setup_abi_env function
> in bin/auto-multilib.sh contains the full list), then does build the package as usual. If additional
> ABIs are requested, it checks after src_install, if there are possible ABI-specific files (libs,
> headers or, if requested for every ABI, also binaries). If those are found, the image dir is moved
> away and a new run is started, where again at start abic-specific vars are set and then the complete
> src* phases are run. Once all requested ABIs are done, the image dirs are merged into the final
> image dir. The following pkg_* phases are each running for every ABI.
> Currently, only different libs and headers are installed by default, binaries will be the ones from
> the default ABI, unless you tell portage to install binaries for all requested ABIs, in which case a
> wrapper will select the ABI-specific binary depending on the environment.
> The current implementation uses a USE-dep like way internally to satisfy the needed dependencies, so
> that e.g. 32bit libs on a 64bit platform get their required dependencies built with 32bit libs
> installed. For the rare case, where the crosscompile does fail and there is only a need for the
> binary and no linking against the libs, i have also a var, which disables this auto-dependency
> calculation for specified packages.
> 
> For the user interface, portage shows a USE_EXPANDed var, which contains the avaidable ABIs, as an
> example for "emerge -pv media-libs/jpeg":
> 
> [ebuild   R   ] media-libs/jpeg-8b  USE="-static-libs" MULTILIB_ABI="amd64 x86"
> 
> Those ABIs can be handled like USE flags, in this case, they are "multilib_abi_amd64" and
> "multilib_abi_x86", so you can use those USE flags to enable/disable specific possible ABIs either
> globally or per package.
> 
> The basic implementation can be used without changing main tree ebuilds or eclasses, but e.g. for
> the replacement of emul-* libs, this will require EAPI-support for ABI-specific USE-deps for
> binary-only packages or packages like wine.
> 
> I would first like to see, if there are any bigger concerns especially with the implementation and
> how it is supposed to work.
> 
> If there are no such concerns or if they have been resolved, i would like to request some help for
> the documentation and PMS-patch related work.
> 
> For install instructions, please have a look at [1], the code can be found in the multilib branch of
> portage git repo at [2].
> 
> While i did not yet get to the implementation of it, i would also like to propose something similiar
> for languages (like python, ruby or others), so that the basic parts are inside the PM and we can
> drop the different ways of implementation and allow users a much more fine-grained control on a per
> package base (in relation to the current way python eclass based very complex implementation works).
> 
> [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc
> [2]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib
> 

Hello

I would like to know what is "blocking" this from landing main tree in
the "near" future, as I reviewed:

http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html

and looks like there wasn't major problems (at least commented in this
thread)

Thanks a lot for the info :-)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: MULTI_ABI support addition to main tree portage

[Nikos Chantziaras]

On 01/29/2011 07:03 PM, Pacho Ramos wrote:
> I would like to know what is "blocking" this from landing main tree in
> the "near" future, as I reviewed:
>
> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html
>
> and looks like there wasn't major problems (at least commented in this
> thread)
>
> Thanks a lot for the info :-)

Heh, me too.  Been waiting for this one like crazy.  The emul- packages 
never worked reliably here.

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Nathan Phillip Brink]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote:
> 
> Hello
> 
> I would like to know what is "blocking" this from landing main tree in
> the "near" future, as I reviewed:
> 
> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html
> 
> and looks like there wasn't major problems (at least commented in this
> thread)

There are still a number of known build failures, tracked in
https://bugs.gentoo.org/alias/portage-multilib . There are probably
many more portage-multilib-related build failures which haven't been
encountered yet nor reported. Also, even these reported bugs are not
necessarily fixed first because they only affect us the minority ;-).

Most everything is easy to debug and as simple as replacing calls to
$(LD) in poorly-written Makefileswith with calls to $(CC), fixing
packages which ignore CFLAGS (where we store our -m32) or LDFLAGS
(where we now also store -m32 since one's not allowed to require
buildsystems to call $(CC) with $(CFLAGS) when objects are being
linked into an executable or library).

However, packages which use qmake or cmake macros installed by KDE are
more difficult to debug and there are other funny issues such as
CFLAGS being stored by a library's buildsystem and stored into
/usr/share instead of an ABI-dependent directory, breaking packages
which use that library... ;-)

Also, there are still some decisions/changes to portage-multilib which
might be made The most recent idea discussed was: should ${ARCH}
useflags (like SRC_URI="x86? ( http://host/my-binari-x86.tar.bz2 )")
be replaced with ${ABI} useflags or should we rewrite a bunch of
ebuilds in the tree to be multilib-aware? For example:

Say we have
ABI=x86
ARCH=amd64

Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''?
Do detect the true arch, do we need ``use arch_amd64'' or does ``use amd64'' still return true?

-- 
binki

Look out for missing apostrophes!

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

El sáb, 29-01-2011 a las 13:10 -0500, Nathan Phillip Brink escribió:
> On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote:
> > 
> > Hello
> > 
> > I would like to know what is "blocking" this from landing main tree in
> > the "near" future, as I reviewed:
> > 
> > http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html
> > 
> > and looks like there wasn't major problems (at least commented in this
> > thread)
> 
> There are still a number of known build failures, tracked in
> https://bugs.gentoo.org/alias/portage-multilib . There are probably
> many more portage-multilib-related build failures which haven't been
> encountered yet nor reported. Also, even these reported bugs are not
> necessarily fixed first because they only affect us the minority ;-).

OK, thanks. Maybe bug 306835 should block bug 145737 instead of
depending on it, not?

> 
> Most everything is easy to debug and as simple as replacing calls to
> $(LD) in poorly-written Makefileswith with calls to $(CC), fixing
> packages which ignore CFLAGS (where we store our -m32) or LDFLAGS
> (where we now also store -m32 since one's not allowed to require
> buildsystems to call $(CC) with $(CFLAGS) when objects are being
> linked into an executable or library).
> 
> However, packages which use qmake or cmake macros installed by KDE are
> more difficult to debug and there are other funny issues such as
> CFLAGS being stored by a library's buildsystem and stored into
> /usr/share instead of an ABI-dependent directory, breaking packages
> which use that library... ;-)
> 
> Also, there are still some decisions/changes to portage-multilib which
> might be made The most recent idea discussed was: should ${ARCH}
> useflags (like SRC_URI="x86? ( http://host/my-binari-x86.tar.bz2 )")
> be replaced with ${ABI} useflags or should we rewrite a bunch of
> ebuilds in the tree to be multilib-aware? For example:
> 
> Say we have
> ABI=x86
> ARCH=amd64
> 
> Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''?
> Do detect the true arch, do we need ``use arch_amd64'' or does ``use amd64'' still return true?
> 

Where do you discuss things like this? IRC channel? Mailing-list?
Thanks :-)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]

Am 29.01.2011 19:30, schrieb Pacho Ramos:
> El sáb, 29-01-2011 a las 13:10 -0500, Nathan Phillip Brink escribió:
>> On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote:
>>>
>>> Hello
>>>
>>> I would like to know what is "blocking" this from landing main tree in
>>> the "near" future, as I reviewed:
>>>
>>> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html
>>>
>>> and looks like there wasn't major problems (at least commented in this
>>> thread)
>>
>> There are still a number of known build failures, tracked in
>> https://bugs.gentoo.org/alias/portage-multilib . There are probably
>> many more portage-multilib-related build failures which haven't been
>> encountered yet nor reported. Also, even these reported bugs are not
>> necessarily fixed first because they only affect us the minority ;-).
> 
> OK, thanks. Maybe bug 306835 should block bug 145737 instead of
> depending on it, not?

I think, they are mostly dublicates, bug 145737 was the original multilib-portage idea of kanaka,
but he discontinued it. The version of today (bug 306835) does partly base on his work and partly on
the work with the native-multilib eclass from some Gentoo users with some additional changes from me.

> 
>>
>> Most everything is easy to debug and as simple as replacing calls to
>> $(LD) in poorly-written Makefileswith with calls to $(CC), fixing
>> packages which ignore CFLAGS (where we store our -m32) or LDFLAGS
>> (where we now also store -m32 since one's not allowed to require
>> buildsystems to call $(CC) with $(CFLAGS) when objects are being
>> linked into an executable or library).
>>
>> However, packages which use qmake or cmake macros installed by KDE are
>> more difficult to debug and there are other funny issues such as
>> CFLAGS being stored by a library's buildsystem and stored into
>> /usr/share instead of an ABI-dependent directory, breaking packages
>> which use that library... ;-)
>>
>> Also, there are still some decisions/changes to portage-multilib which
>> might be made The most recent idea discussed was: should ${ARCH}
>> useflags (like SRC_URI="x86? ( http://host/my-binari-x86.tar.bz2 )")
>> be replaced with ${ABI} useflags or should we rewrite a bunch of
>> ebuilds in the tree to be multilib-aware? For example:
>>
>> Say we have
>> ABI=x86
>> ARCH=amd64
>>
>> Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''?
>> Do detect the true arch, do we need ``use arch_amd64'' or does ``use amd64'' still return true?
>>
> 
> Where do you discuss things like this? IRC channel? Mailing-list?
> Thanks :-)

Most communication is done in #gentoo-multilib-overlay on freenode IRC. I have also created a mail
alias (multilib@g.o), but it is only used for some bugzilla assignments at the moment.


-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

El sáb, 29-01-2011 a las 19:56 +0100, Thomas Sachau escribió:
> Am 29.01.2011 19:30, schrieb Pacho Ramos:
> > El sáb, 29-01-2011 a las 13:10 -0500, Nathan Phillip Brink escribió:
> >> On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote:
> >>>
> >>> Hello
> >>>
> >>> I would like to know what is "blocking" this from landing main tree in
> >>> the "near" future, as I reviewed:
> >>>
> >>> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html
> >>>
> >>> and looks like there wasn't major problems (at least commented in this
> >>> thread)
> >>
> >> There are still a number of known build failures, tracked in
> >> https://bugs.gentoo.org/alias/portage-multilib . There are probably
> >> many more portage-multilib-related build failures which haven't been
> >> encountered yet nor reported. Also, even these reported bugs are not
> >> necessarily fixed first because they only affect us the minority ;-).
> > 
> > OK, thanks. Maybe bug 306835 should block bug 145737 instead of
> > depending on it, not?
> 
> I think, they are mostly dublicates, bug 145737 was the original multilib-portage idea of kanaka,
> but he discontinued it. The version of today (bug 306835) does partly base on his work and partly on
> the work with the native-multilib eclass from some Gentoo users with some additional changes from me.
> 
> > 
> >>
> >> Most everything is easy to debug and as simple as replacing calls to
> >> $(LD) in poorly-written Makefileswith with calls to $(CC), fixing
> >> packages which ignore CFLAGS (where we store our -m32) or LDFLAGS
> >> (where we now also store -m32 since one's not allowed to require
> >> buildsystems to call $(CC) with $(CFLAGS) when objects are being
> >> linked into an executable or library).
> >>
> >> However, packages which use qmake or cmake macros installed by KDE are
> >> more difficult to debug and there are other funny issues such as
> >> CFLAGS being stored by a library's buildsystem and stored into
> >> /usr/share instead of an ABI-dependent directory, breaking packages
> >> which use that library... ;-)
> >>
> >> Also, there are still some decisions/changes to portage-multilib which
> >> might be made The most recent idea discussed was: should ${ARCH}
> >> useflags (like SRC_URI="x86? ( http://host/my-binari-x86.tar.bz2 )")
> >> be replaced with ${ABI} useflags or should we rewrite a bunch of
> >> ebuilds in the tree to be multilib-aware? For example:
> >>
> >> Say we have
> >> ABI=x86
> >> ARCH=amd64
> >>
> >> Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''?
> >> Do detect the true arch, do we need ``use arch_amd64'' or does ``use amd64'' still return true?
> >>
> > 
> > Where do you discuss things like this? IRC channel? Mailing-list?
> > Thanks :-)
> 
> Most communication is done in #gentoo-multilib-overlay on freenode IRC. I have also created a mail
> alias (multilib@g.o), but it is only used for some bugzilla assignments at the moment.
> 
> 

OK, thanks a lot

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]