1 |
On Mon, 4 Mar 2013 21:49:48 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> On Mon, 4 Mar 2013 11:02:40 +0100 |
5 |
> Alexis Ballier <aballier@g.o> wrote: |
6 |
> |
7 |
> > On Sun, 3 Mar 2013 23:25:03 +0100 |
8 |
> > Michał Górny <mgorny@g.o> wrote: |
9 |
> > |
10 |
> > > On Sun, 3 Mar 2013 18:18:12 +0100 |
11 |
> > > Alexis Ballier <aballier@g.o> wrote: |
12 |
> > > |
13 |
> > > > On Sun, 3 Mar 2013 17:58:26 +0100 |
14 |
> > > > Michał Górny <mgorny@g.o> wrote: |
15 |
> > > > |
16 |
> > > > > What do we need that wrapper for? What does the wrapper do? |
17 |
> > > > > Does it just rely on custom 'ABI' variable? |
18 |
> > > > |
19 |
> > > > yes -- it must perform some checks though. |
20 |
> > > |
21 |
> > > What kind of checks? |
22 |
> > |
23 |
> > you are called with ABI=sth argv[0] = your name |
24 |
> |
25 |
> I'm afraid that's the first potential point of failure. Relying |
26 |
> on argv[0] is a poor idea and means that any application calling |
27 |
> exec() with changed argv[0] on a wrapped binary will fail terribly. |
28 |
|
29 |
Go tell that to those that wrote busybox, tex or git: They all use |
30 |
that argv trick :) I'm sure there are plenty of other examples and |
31 |
don't consider that a poor idea. Note that the wrapper does not lie on |
32 |
argv: it just makes the binary think it has its original name (by |
33 |
passing argv as is) while it has been moved to allow parallel |
34 |
installation of different flavors of it. |
35 |
|
36 |
> > if argv[0] = abiwrapper -> print some information and exit |
37 |
> > getenv ABI -> if nothing then set ABI=$DEFAULT_ABI (hardcoded at |
38 |
> > buildtime of the wrapper) |
39 |
> > execvp(argv[0]_$ABI, argv) |
40 |
> > if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI |
41 |
> > |
42 |
> > |
43 |
> > python-wrapper.c is very likely to have such a logic already. |
44 |
> > |
45 |
> > btw, IMHO ABI is a too common name for such a variable, I'd better |
46 |
> > name it something like _GENTOO_MULTILIB_ABI so that collisions are |
47 |
> > much less likely. |
48 |
> |
49 |
> I'm afraid you are actually starting to go the other way. |
50 |
> |
51 |
> Global wrapper means that it is potentially useful to our users. |
52 |
> However I don't really see people who want to compile 32-bit |
53 |
> executables think of setting some custom variable like ABI. |
54 |
|
55 |
They will not: Users will call the name-suffixed version directly. If |
56 |
they call the non-suffixed version then the above logic will run the |
57 |
DEFAULT_ABI version. There's no variable to set. |
58 |
The variable is more so that ebuilds/eclasses can set the variable and |
59 |
be done. Exactly like EPYTHON I think. |
60 |
|
61 |
|
62 |
[...] |
63 |
> > That's why I asked for examples :) |
64 |
> > qmake may do it, I don't think its sane, but that's life for now. |
65 |
> > having glxinfo for each abi is useful from a user perspective (it |
66 |
> > does not need the wrapper a priori though) |
67 |
> |
68 |
> Yep, I intended to just have the additional variant of glxinfo |
69 |
> directly callable, with a name chosen specifically by the X11 team. |
70 |
> Wrapper would be more confusing than beneficial here IMO. |
71 |
|
72 |
Having a wrapper or not, for the end user that does not know the |
73 |
internal variable name, the end-result will be exactly the same :) |
74 |
|
75 |
[...] |
76 |
> > See it something like python-wrapper. EPYTHON=python3.2 python -> |
77 |
> > runs python3.2 :) |
78 |
> |
79 |
> Err, python-wrapper respects quite complex logic involving EPYTHON, |
80 |
> and eselect-python. We don't really want people to have eselect-abi, |
81 |
> do we? |
82 |
|
83 |
No we don't. The wrapper has nothing to do with that. |
84 |
|
85 |
[...] |
86 |
> > To some extent that's what happened to python too :) As a python |
87 |
> > maintainer, you could share your thoughts on the topic. python |
88 |
> > slotting was intended to make switching between python versions |
89 |
> > easy but has been needing wrappers for the python binary. |
90 |
> |
91 |
> I'm doing just that. Any kind of wrapping is an increasing mess. I'm |
92 |
> still trying to find out good solutions for Python wrapping but |
93 |
> there's no such thing. It's always about choosing one evil over the |
94 |
> other. |
95 |
|
96 |
I don't understand here. What is python-wrapper good for if that's not |
97 |
to be able to chose which python to run within ebuilds? If that's just |
98 |
for eselecting the active version, a symlink is likely to be enough. |
99 |
python-wrapper is an elegant idea for not having to invent a new way |
100 |
and change everything else: Within an ebuild, setting EPYTHON lets you |
101 |
be certain that everything will be run by the version you want. You do |
102 |
not have to mess with packages calling 'python' directly. |
103 |
|
104 |
[...] |
105 |
> > packages |
106 |
> > calling directly binaries having ABI specific output will be broken |
107 |
> > for multilib too (and I don't know of anyone checking for this |
108 |
> > while the other two have been long standing issues we tried to |
109 |
> > fix). We can fix this, but the fact is that we need multi-binary |
110 |
> > support for users, then the only choice to make is if we want to |
111 |
> > provide a wrapper so that we do not need to fix build systems or if |
112 |
> > we want to fix them. The latter is likely preferred but I do not |
113 |
> > know what kind of work it will involve. It'd help if tommy could |
114 |
> > provide a list of binaries he needed to wrap through the abiwrapper. |
115 |
> |
116 |
> We don't want it for users in an automagic and fragile way. And |
117 |
> ebuilds we can fix while migrating. |
118 |
|
119 |
I think you misunderstood the idea of the wrapper: It seems more robust |
120 |
than anything else. |
121 |
|
122 |
Consider the following scenario: |
123 |
The binary foo transforms a .foo file into a .h file. .foo files define |
124 |
types foo32 and foo64. The foo utility, while processing its .foo |
125 |
files, #define them to, respectively, long and long long on x86 |
126 |
and int and long on amd64. Its output depends on the ABI, so we install |
127 |
foo and foo_x86 for an amd64/x86 multilib system. |
128 |
|
129 |
Now I have a package that uses .foo files: it installs several |
130 |
libraries and binaries and seems to accept FOO='name of the foo utility' |
131 |
variables. Good, so we set FOO=foo_${ABI} or FOO=foo depending on what |
132 |
we are building for. All seems good. But one of all its libraries |
133 |
has an hardcoded foo call. Your package will build fine but x86 |
134 |
binaries using this library will except the foo_x86 types of abi, |
135 |
however this library was built with foo_amd64 types: the foo64 |
136 |
types will actually be 32bits for this sole library. Calling a |
137 |
function with a foo64 argument from this library will corrupt the stack |
138 |
and you will get weird crashes, usually very hard to debug. |
139 |
|
140 |
|
141 |
This is an extreme and stupid example, but without any wrapper and with |
142 |
ABI-specific output used within ebuilds and build systems, you have to |
143 |
be *very* careful that the correct tool is *always* called. |
144 |
The wrapper is only a way to ensure that after all :) |
145 |
|
146 |
|
147 |
Alexis. |