1 |
On Mon, 4 Mar 2013 11:02:40 +0100 |
2 |
Alexis Ballier <aballier@g.o> wrote: |
3 |
|
4 |
> On Sun, 3 Mar 2013 23:25:03 +0100 |
5 |
> Michał Górny <mgorny@g.o> wrote: |
6 |
> |
7 |
> > On Sun, 3 Mar 2013 18:18:12 +0100 |
8 |
> > Alexis Ballier <aballier@g.o> wrote: |
9 |
> > |
10 |
> > > On Sun, 3 Mar 2013 17:58:26 +0100 |
11 |
> > > Michał Górny <mgorny@g.o> wrote: |
12 |
> > > |
13 |
> > > > What do we need that wrapper for? What does the wrapper do? Does |
14 |
> > > > it just rely on custom 'ABI' variable? |
15 |
> > > |
16 |
> > > yes -- it must perform some checks though. |
17 |
> > |
18 |
> > What kind of checks? |
19 |
> |
20 |
> you are called with ABI=sth argv[0] = your name |
21 |
|
22 |
I'm afraid that's the first potential point of failure. Relying |
23 |
on argv[0] is a poor idea and means that any application calling exec() |
24 |
with changed argv[0] on a wrapped binary will fail terribly. |
25 |
|
26 |
> if argv[0] = abiwrapper -> print some information and exit |
27 |
> getenv ABI -> if nothing then set ABI=$DEFAULT_ABI (hardcoded at |
28 |
> buildtime of the wrapper) |
29 |
> execvp(argv[0]_$ABI, argv) |
30 |
> if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI |
31 |
> |
32 |
> |
33 |
> python-wrapper.c is very likely to have such a logic already. |
34 |
> |
35 |
> btw, IMHO ABI is a too common name for such a variable, I'd better name |
36 |
> it something like _GENTOO_MULTILIB_ABI so that collisions are much less |
37 |
> likely. |
38 |
|
39 |
I'm afraid you are actually starting to go the other way. |
40 |
|
41 |
Global wrapper means that it is potentially useful to our users. |
42 |
However I don't really see people who want to compile 32-bit |
43 |
executables think of setting some custom variable like ABI. |
44 |
|
45 |
Moreover, if we replace that with a specific, 'private' environment |
46 |
variable like you suggested, we're actually discouraging people from |
47 |
using it. So, we're force-installing wrappers which make things fragile |
48 |
and at the same time provide no benefit for regular users. |
49 |
|
50 |
> > > > Or maybe should it try to detect |
51 |
> > > > whether it was called by a 64- or 32-bit app? |
52 |
> > > |
53 |
> > > this wont work: think about a build system, your shell/make will |
54 |
> > > likely be your default abi's but may call abi-specific tools |
55 |
> > > depending on what you build _for_ not what you build _with_ |
56 |
> > |
57 |
> > That's one side of it. The other is that if it worked, it may be |
58 |
> > something really unexpected. Do you expect things to work differently |
59 |
> > when called by a 32-bit program? |
60 |
> |
61 |
> That's why I asked for examples :) |
62 |
> qmake may do it, I don't think its sane, but that's life for now. |
63 |
> having glxinfo for each abi is useful from a user perspective (it does |
64 |
> not need the wrapper a priori though) |
65 |
|
66 |
Yep, I intended to just have the additional variant of glxinfo directly |
67 |
callable, with a name chosen specifically by the X11 team. Wrapper |
68 |
would be more confusing than beneficial here IMO. |
69 |
|
70 |
> > > > What for? |
71 |
> > > |
72 |
> > > in order to be transparent from the ebuild perspective. |
73 |
> > |
74 |
> > That depends on what kind of transparency do we want. I prefer being |
75 |
> > explicit here rather than assuming something you can't know for sure. |
76 |
> |
77 |
> See it something like python-wrapper. EPYTHON=python3.2 python -> runs |
78 |
> python3.2 :) |
79 |
|
80 |
Err, python-wrapper respects quite complex logic involving EPYTHON, |
81 |
and eselect-python. We don't really want people to have eselect-abi, |
82 |
do we? |
83 |
|
84 |
If we were to implement abi-wrapper, it will be much simpler than any |
85 |
logic needed for Python. |
86 |
|
87 |
> > I think we're starting to miss the point of multilib. Multilib was |
88 |
> > intended as a cheap way of getting things working. I believe that we |
89 |
> > should still consider it so, and keep it in cages rather than |
90 |
> > believing that the world is more fun with tigers jumping around. |
91 |
> > |
92 |
> > That said, I wouldn't say that making random executables in system |
93 |
> > work differently on ${ABI} is a way to go. That leaves the tricky |
94 |
> > imprint of multilib visible to users who shouldn't care about it. If |
95 |
> > they do, they're looking for multilib-portage. |
96 |
> |
97 |
> To some extent that's what happened to python too :) As a python |
98 |
> maintainer, you could share your thoughts on the topic. python slotting |
99 |
> was intended to make switching between python versions easy but has |
100 |
> been needing wrappers for the python binary. |
101 |
|
102 |
I'm doing just that. Any kind of wrapping is an increasing mess. I'm |
103 |
still trying to find out good solutions for Python wrapping but there's |
104 |
no such thing. It's always about choosing one evil over the other. |
105 |
|
106 |
> > The whole 'switching' part of multilib should be kept part of our |
107 |
> > build system -- eclasses, ebuilds or just some specificities like |
108 |
> > libdir or pkg-config path switching. |
109 |
> |
110 |
> Maybe, but that would involve perfectly working setups being "broken". |
111 |
> It's like packages not respecting CC being broken for cross-compiling, |
112 |
> those not respecting CFLAGS being broken for multilib, etc. |
113 |
|
114 |
Just to make it clear, multilib.eclass overrides CC for multilib. It |
115 |
does not rely on CFLAGS. I don't know the rationale, I can guess only. |
116 |
|
117 |
> packages |
118 |
> calling directly binaries having ABI specific output will be broken for |
119 |
> multilib too (and I don't know of anyone checking for this while the |
120 |
> other two have been long standing issues we tried to fix). We can fix |
121 |
> this, but the fact is that we need multi-binary support for users, then |
122 |
> the only choice to make is if we want to provide a wrapper so that we |
123 |
> do not need to fix build systems or if we want to fix them. The latter |
124 |
> is likely preferred but I do not know what kind of work it will involve. |
125 |
> It'd help if tommy could provide a list of binaries he needed to wrap |
126 |
> through the abiwrapper. |
127 |
|
128 |
We don't want it for users in an automagic and fragile way. And ebuilds |
129 |
we can fix while migrating. |
130 |
|
131 |
-- |
132 |
Best regards, |
133 |
Michał Górny |