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

[Michał Górny]

On Sat, 9 Mar 2013 11:10:11 +0100
Alexis Ballier <aballier@g.o> wrote:

> On Fri, 8 Mar 2013 17:30:10 +0100
> Michał Górny <mgorny@g.o> wrote:
>
> > 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 :)

Help message won't help users.

  We're very sorry, that won't work. Don't bother reporting it to
  upstream, it's Gentoo-specific hack, they'll just WONTFIX them. Feel
  free to report it here, we may be able to clean the mess up someday.

We're basically talking about opt-out. We introduce a trick which fails
in corner cases by default, hoping those cases won't happen. People
start to rely on it. Then the corner case happens and we need to
opt-out, and we need to fix everything that started to rely
on the common case working.

> 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?

I think that was one of the things that were pointed out in the initial
python-exec implementation. It's not broken that much as a bit
inconsistent by design. As in, wrapper /usr/bin/foo-config doesn't
guarantee that /usr/bin/foo-config-${ARCH} will be called (maybe
something in /usr/local/bin or somewhere completely different?).

> 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 :)

Well, yes. In the worst case we could go that way, although it's a bit
of overkill, don't you think? While we're talking about a few programs
which will actually need it, and even less which will require
modification in more than one place.

> 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.

Choose optimal solution per-package. In case of freetype, the solution
is simple enough: make multilib-aware packages use pkg-config.
fontconfig does exactly that, and in the earlier version it was enough
to export something like FREETYPE_CONFIG='pkg-config freetype2'
(or ac_cv...).

In LLVM, for example, we were considering just calling the proper
config by hand. It's a single multilib package which will need it now,
so it's not that problematic.

If you have any specific -config scripts in mind, please point me
to them. By the way, from what I recall Tommy said that llvm is
basically the only -config script being actually compiled executable.

-- 
Best regards,
Michał Górny