Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

[Thomas Sachau]

Alexis Ballier schrieb:
> On Sun, 3 Mar 2013 23:25:03 +0100
> Michał Górny <mgorny@g.o> wrote:
>
>> On Sun, 3 Mar 2013 18:18:12 +0100
>> Alexis Ballier <aballier@g.o> wrote:
>>
>>> On Sun, 3 Mar 2013 17:58:26 +0100
>>> Michał Górny <mgorny@g.o> wrote:
>>>
>>>> What do we need that wrapper for? What does the wrapper do? Does
>>>> it just rely on custom 'ABI' variable?
>>>
>>> yes -- it must perform some checks though.
>>
>> What kind of checks?
>
> you are called with ABI=sth argv[0] = your name
> if argv[0] = abiwrapper -> print some information and exit
> getenv ABI -> if nothing then set ABI=$DEFAULT_ABI (hardcoded at
> buildtime of the wrapper)
> execvp(argv[0]_$ABI, argv)
> if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI
>
>
> python-wrapper.c is very likely to have such a logic already.
>
> btw, IMHO ABI is a too common name for such a variable, I'd better name
> it something like _GENTOO_MULTILIB_ABI so that collisions are much less
> likely.
>
>>>> Or maybe should it try to detect
>>>> whether it was called by a 64- or 32-bit app?
>>>
>>> this wont work: think about a build system, your shell/make will
>>> likely be your default abi's but may call abi-specific tools
>>> depending on what you build _for_ not what you build _with_
>>
>> That's one side of it. The other is that if it worked, it may be
>> something really unexpected. Do you expect things to work differently
>> when called by a 32-bit program?
>
> That's why I asked for examples :)
> qmake may do it, I don't think its sane, but that's life for now.
> having glxinfo for each abi is useful from a user perspective (it does
> not need the wrapper a priori though)
>
>
>>>> What for?
>>>
>>> in order to be transparent from the ebuild perspective.
>>
>> That depends on what kind of transparency do we want. I prefer being
>> explicit here rather than assuming something you can't know for sure.
>
> See it something like python-wrapper. EPYTHON=python3.2 python -> runs
> python3.2 :)
>
>> I think we're starting to miss the point of multilib. Multilib was
>> intended as a cheap way of getting things working. I believe that we
>> should still consider it so, and keep it in cages rather than
>> believing that the world is more fun with tigers jumping around.
>>
>> That said, I wouldn't say that making random executables in system
>> work differently on ${ABI} is a way to go. That leaves the tricky
>> imprint of multilib visible to users who shouldn't care about it. If
>> they do, they're looking for multilib-portage.
>
> To some extent that's what happened to python too :) As a python
> maintainer, you could share your thoughts on the topic. python slotting
> was intended to make switching between python versions easy but has
> been needing wrappers for the python binary.
>
>> The whole 'switching' part of multilib should be kept part of our
>> build system -- eclasses, ebuilds or just some specificities like
>> libdir or pkg-config path switching.
>
> Maybe, but that would involve perfectly working setups being "broken".
> It's like packages not respecting CC being broken for cross-compiling,
> those not respecting CFLAGS being broken for multilib, etc. packages
> calling directly binaries having ABI specific output will be broken for
> multilib too (and I don't know of anyone checking for this while the
> other two have been long standing issues we tried to fix). We can fix
> this, but the fact is that we need multi-binary support for users, then
> the only choice to make is if we want to provide a wrapper so that we
> do not need to fix build systems or if we want to fix them. The latter
> is likely preferred but I do not know what kind of work it will involve.
> It'd help if tommy could provide a list of binaries he needed to wrap
> through the abiwrapper.
>
> Alexis.
>

The actual list of packages with wrapped binaries is in the profiles dir
of the multilib-portage overlay (expect this to be a minimal list, there
are probably more out there we did not yet catch):

dev-db/mysql abiwrapper
dev-lang/perl abiwrapper
dev-lang/python abiwrapper
dev-lang/ruby abiwrapper
dev-libs/gobject-introspection abiwrapper
dev-libs/libIDL abiwrapper
dev-scheme/guile abiwrapper
net-libs/courier-authlib abiwrapper
dev-qt/qtcore abiwrapper
dev-qt/qtgui abiwrapper
media-libs/fontconfig abiwrapper
www-servers/apache abiwrapper
x11-libs/pango abiwrapper
x11-libs/gtk+ abiwrapper

Keep in mind, that multilib-portage does always and unconditionally wrap
*-config binaries. If you dont want to add that logic to the eclass, you
need to add all packages providing such files to the list.

-- 

Thomas Sachau
Gentoo Linux Developer