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

[Alexis Ballier]

On Fri, 8 Mar 2013 17:30:10 +0100
Michał Górny <mgorny@g.o> wrote:

> On Thu, 7 Mar 2013 17:25:23 +0100
> Alexis Ballier <aballier@g.o> wrote:
>
> > On Mon, 4 Mar 2013 21:49:48 +0100
> > Michał Górny <mgorny@g.o> wrote:
> >
> > > 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.
> >
> > Go tell that to those that wrote busybox, tex or git: They all use
> > that argv trick :) I'm sure there are plenty of other examples and
> > don't consider that a poor idea. Note that the wrapper does not lie
> > on argv: it just makes the binary think it has its original name (by
> > passing argv as is) while it has been moved to allow parallel
> > installation of different flavors of it.
>
> We're talking about two different tricks.
>
> Busybox checks argv to support symlinking for a standard tool. With
> invalid argv[0], it still runs as the standard busybox binary. You can
> use it that way, the 'safe way'.
>
> Unless I'm missing something, git checks argv to support symlinking
> into a few dozen tools which is optional. I doubt most of our users
> rely on that rather than using the 'git foo' syntax.
>
> A wrapper needs valid argv[0] to find the actual executable. Since
> argv[0] is unlikely to contain a path, that's either reinventing some
> logic or execvp() which is a bit fragile. Plus symlink resolution
> loop. Hard links do not work at all.
>
> And that's just theory. I may be missing some of the dangers.

abiwrapper with invalid argv will print a standard help message too :)
I don't see why you consider execvp fragile: Don't tell me you run all
your binaries with full path.

Of course you can break it, but the question is more: Is it likely to
break in a real life situation?

If you consider the argv trick fragile, which is understandable, the
same wrapper idea can be used differently: If you want to wrap a
binary foo, move it to foo_${abi} and build a wrapper with hardcoded
'foo' instead of argv[0] that you install as foo. You can even hardcode
its path and use execv instead of execvp. That would invalidate all
your above objections I think :)

> > > 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.
> >
> > They will not: Users will call the name-suffixed version directly.
> > If they call the non-suffixed version then the above logic will run
> > the DEFAULT_ABI version. There's no variable to set.
>
> So there's no benefit from the wrapper to the users. We're talking
> about a solution which is purely disadvantageous to them.

The wrapper is not for users at all...

You can very well have two different ways of installing
multilib-binaries also: one with an array mapping (abi,binary) to
(renamed_binary), without wrapping at all, which is what you seem to
want for glxinfo. Another one with the full wrapping mechanism to make
multilib builds of dependent packages easier/doable.

> > The variable is more so that ebuilds/eclasses can set the variable
> > and be done. Exactly like EPYTHON I think.
>
> Python is almost a completely different issue. Most importantly, we
> support multiple Python versions, and have to maintain all of them.
> That support is extended to all packages in the tree, and is achieved
> with no major losses.
>
> We're talking about having multilib for a few chosen packages, and yet
> introducing a tree-wide solution to hack-around even less of them.
> A hack-around which has visible disadvantages.

That's why we are currently discussing how to do it properly :P
Let alone qmake, how do you suggest dealing with *-config scripts?
Some packages are just not written with multilib in mind, or have
to maintain historical compatibility which was not, wrapping the
problematic binaries is one solution to this. I've not seen any other
solution.

> > [...]
> > > > 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.
> >
> > Having a wrapper or not, for the end user that does not know the
> > internal variable name, the end-result will be exactly the same :)
>
> Unless he symlinked the tool. Then it simply won't work for him
> anymore.

Well, this is a non-issue with the 'one wrapper with hardcoded names
per binary' approach above.

> > This is an extreme and stupid example, but without any wrapper and
> > with ABI-specific output used within ebuilds and build systems, you
> > have to be *very* careful that the correct tool is *always* called.
> > The wrapper is only a way to ensure that after all :)
>
> The main point is to enforce ebuild developers to be careful while
> handling multilib. This is the main difference from Tommy's solution
> -- I don't want people to switch the 'multilib' flag on ebuilds
> thoughtlessly and expect everything to work without changing the
> ebuild.

Yes, and we want to do it properly. So far the only solution I've seen
for *-config scripts is a wrapper. The qmake case has to be analyzed,
maybe its doable in a better way without wrapper.
Unless someone comes with a sane different solution for *-config
scripts, I still think the wrapper is the only solution to these.

Alexis.