Gentoo Archives: gentoo-dev

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
Date: Fri, 08 Mar 2013 18:02:04
Message-Id: 20130308182513.GB1440@rathaus.eclipse.co.uk
In Reply to: Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs by Thomas Sachau
1 On Mon, Mar 04, 2013 at 11:21:36PM +0100, Thomas Sachau wrote:
2 > Michał Górny schrieb:
3 > > On Mon, 4 Mar 2013 11:02:40 +0100
4 > > Alexis Ballier <aballier@g.o> wrote:
5 > >> you are called with ABI=sth argv[0] = your name
6 > >
7 > > I'm afraid that's the first potential point of failure. Relying
8 > > on argv[0] is a poor idea and means that any application calling exec()
9 > > with changed argv[0] on a wrapped binary will fail terribly.
10 >
11 > Nobody said, that one cannot create situations, where such a wrapper
12 > does fail, the point is more an easy and general solution for wrapping
13 > binaries without implementing different solutions for the same issue in
14 > every ebuild.
15 >
16 > If you have a better, yet still easy and general solution not requiring
17 > every ebuild to create something on its own, please write it instead of
18 > just complaining how bad the wrapper solution actually is.
19
20 Why not just custom-compile the wrapper so the path to what it is wrapping
21 is hard-coded? After all, you've moved the original binary out of PATH so
22 that the wrapper gets called instead, and you're hardcoding the default ABI
23 at build-time.
24
25 That way it doesn't matter what argv[0] is, it'll always exec either of the
26 binaries it was installed for, and the user can symlink to it as normal.
27 (testing for 'abiwrapper' can still be done.)
28
29 Admittedly it adds a little complexity, but not much, and it's automated so
30 once the kinks are worked out it should be fire and forget. Personally, I'd
31 go for explicitly stating which binaries to wrap, but either way it's hardly
32 going to add a significant amount of compilation time to a mysql build.
33
34 > >> if argv[0] = abiwrapper -> print some information and exit
35 > >> getenv ABI -> if nothing then set ABI=$DEFAULT_ABI (hardcoded at
36 > >> buildtime of the wrapper)
37 > >> execvp(argv[0]_$ABI, argv)
38 > >> if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI
39 > >>
40 > >> python-wrapper.c is very likely to have such a logic already.
41 > >>
42 > >> btw, IMHO ABI is a too common name for such a variable, I'd better name
43 > >> it something like _GENTOO_MULTILIB_ABI so that collisions are much less
44 > >> likely.
45 > >
46 > > I'm afraid you are actually starting to go the other way.
47 > >
48 > > Global wrapper means that it is potentially useful to our users.
49 > > However I don't really see people who want to compile 32-bit
50 > > executables think of setting some custom variable like ABI.
51 >
52 > Unless you implied, that you want users to compile from hand instead of
53 > using an ebuild, this makes no sense to me.
54
55 I think there's confusion over ebuild and runtime here. But you did mention
56 getenv("ABI"); in the wrapper, so it's only natural, and I'm not sure what
57 you mean either ;)
58
59 I agree with Thomas that a longer name makes sense in ebuild space (ABI is
60 far too likely to crop up in a build-system), and with Michal that using
61 ABI=x86 foo .. is a bit odd. But how else are you going to switch ABI at
62 runtime if not with an environment variable? --abi=x86 would be nice, but that
63 impinges on the called binary, and is nowhere near as convenient as a simple
64 export.
65
66 GENTOO_ABI=foo gets my vote so far, fwtw.
67
68 --
69 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)