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

[Thomas Sachau]

Michał Górny schrieb:
> On Mon, 4 Mar 2013 11:02:40 +0100
> Alexis Ballier <aballier@g.o> wrote:
>
>> 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
>
> I'm afraid that's the first potential point of failure. Relying
> on argv[0] is a poor idea and means that any application calling exec()
> with changed argv[0] on a wrapped binary will fail terribly.

Nobody said, that one cannot create situations, where such a wrapper
does fail, the point is more an easy and general solution for wrapping
binaries without implementing different solutions for the same issue in
every ebuild.

If you have a better, yet still easy and general solution not requiring
every ebuild to create something on its own, please write it instead of
just complaining how bad the wrapper solution actually is.

>
>> 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.
>
> I'm afraid you are actually starting to go the other way.
>
> Global wrapper means that it is potentially useful to our users.
> However I don't really see people who want to compile 32-bit
> executables think of setting some custom variable like ABI.

Unless you implied, that you want users to compile from hand instead of
using an ebuild, this makes no sense to me.

This ABI variable is of course set when setting up the environment, so
it is around in every phase and any call to an abi-wrapped binary
directly gets the right one for the current ABI.

>>>>> 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)
>
> Yep, I intended to just have the additional variant of glxinfo directly
> callable, with a name chosen specifically by the X11 team. Wrapper
> would be more confusing than beneficial here IMO.

Ah, you actually want each ebuild to have its own custom hack instead of
one global solution usable everywhere?

>
>>>>> 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 :)
>
> Err, python-wrapper respects quite complex logic involving EPYTHON,
> and eselect-python. We don't really want people to have eselect-abi,
> do we?
>
> If we were to implement abi-wrapper, it will be much simpler than any
> logic needed for Python.

Exactly: Just the environment variable, no eselect module, simple, easy
to understand and working.

>
>>> 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.
>
> I'm doing just that. Any kind of wrapping is an increasing mess. I'm
> still trying to find out good solutions for Python wrapping but there's
> no such thing. It's always about choosing one evil over the other.

So you are wrapping python, have not yet found anything better and still
dont want to wrap abi-specific binaries, while you dont have a better
solution at hand? Saying no to everything is easy, providing something
better if you dont like a suggestion is the challenge.

-- 

Thomas Sachau
Gentoo Linux Developer