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