On Mon, Mar 04, 2013 at 11:21:36PM +0100, Thomas Sachau wrote:
> Michał Górny schrieb:
> > On Mon, 4 Mar 2013 11:02:40 +0100
> > Alexis Ballier <aball...@gentoo.org> wrote:
> >> 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.
Why not just custom-compile the wrapper so the path to what it is wrapping
is hard-coded? After all, you've moved the original binary out of PATH so
that the wrapper gets called instead, and you're hardcoding the default ABI
at build-time.
That way it doesn't matter what argv[0] is, it'll always exec either of the
binaries it was installed for, and the user can symlink to it as normal.
(testing for 'abiwrapper' can still be done.)
Admittedly it adds a little complexity, but not much, and it's automated so
once the kinks are worked out it should be fire and forget. Personally, I'd
go for explicitly stating which binaries to wrap, but either way it's hardly
going to add a significant amount of compilation time to a mysql build.
> >> 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.
I think there's confusion over ebuild and runtime here. But you did mention
getenv("ABI"); in the wrapper, so it's only natural, and I'm not sure what
you mean either ;)
I agree with Thomas that a longer name makes sense in ebuild space (ABI is
far too likely to crop up in a build-system), and with Michal that using
ABI=x86 foo .. is a bit odd. But how else are you going to switch ABI at
runtime if not with an environment variable? --abi=x86 would be nice, but that
impinges on the called binary, and is nowhere near as convenient as a simple
export.
GENTOO_ABI=foo gets my vote so far, fwtw.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
