1 |
On Sun, 3 Mar 2013 23:25:03 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> On Sun, 3 Mar 2013 18:18:12 +0100 |
5 |
> Alexis Ballier <aballier@g.o> wrote: |
6 |
> |
7 |
> > On Sun, 3 Mar 2013 17:58:26 +0100 |
8 |
> > Michał Górny <mgorny@g.o> wrote: |
9 |
> > |
10 |
> > > What do we need that wrapper for? What does the wrapper do? Does |
11 |
> > > it just rely on custom 'ABI' variable? |
12 |
> > |
13 |
> > yes -- it must perform some checks though. |
14 |
> |
15 |
> What kind of checks? |
16 |
|
17 |
you are called with ABI=sth argv[0] = your name |
18 |
if argv[0] = abiwrapper -> print some information and exit |
19 |
getenv ABI -> if nothing then set ABI=$DEFAULT_ABI (hardcoded at |
20 |
buildtime of the wrapper) |
21 |
execvp(argv[0]_$ABI, argv) |
22 |
if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI |
23 |
|
24 |
|
25 |
python-wrapper.c is very likely to have such a logic already. |
26 |
|
27 |
btw, IMHO ABI is a too common name for such a variable, I'd better name |
28 |
it something like _GENTOO_MULTILIB_ABI so that collisions are much less |
29 |
likely. |
30 |
|
31 |
> > > Or maybe should it try to detect |
32 |
> > > whether it was called by a 64- or 32-bit app? |
33 |
> > |
34 |
> > this wont work: think about a build system, your shell/make will |
35 |
> > likely be your default abi's but may call abi-specific tools |
36 |
> > depending on what you build _for_ not what you build _with_ |
37 |
> |
38 |
> That's one side of it. The other is that if it worked, it may be |
39 |
> something really unexpected. Do you expect things to work differently |
40 |
> when called by a 32-bit program? |
41 |
|
42 |
That's why I asked for examples :) |
43 |
qmake may do it, I don't think its sane, but that's life for now. |
44 |
having glxinfo for each abi is useful from a user perspective (it does |
45 |
not need the wrapper a priori though) |
46 |
|
47 |
|
48 |
> > > What for? |
49 |
> > |
50 |
> > in order to be transparent from the ebuild perspective. |
51 |
> |
52 |
> That depends on what kind of transparency do we want. I prefer being |
53 |
> explicit here rather than assuming something you can't know for sure. |
54 |
|
55 |
See it something like python-wrapper. EPYTHON=python3.2 python -> runs |
56 |
python3.2 :) |
57 |
|
58 |
> I think we're starting to miss the point of multilib. Multilib was |
59 |
> intended as a cheap way of getting things working. I believe that we |
60 |
> should still consider it so, and keep it in cages rather than |
61 |
> believing that the world is more fun with tigers jumping around. |
62 |
> |
63 |
> That said, I wouldn't say that making random executables in system |
64 |
> work differently on ${ABI} is a way to go. That leaves the tricky |
65 |
> imprint of multilib visible to users who shouldn't care about it. If |
66 |
> they do, they're looking for multilib-portage. |
67 |
|
68 |
To some extent that's what happened to python too :) As a python |
69 |
maintainer, you could share your thoughts on the topic. python slotting |
70 |
was intended to make switching between python versions easy but has |
71 |
been needing wrappers for the python binary. |
72 |
|
73 |
> The whole 'switching' part of multilib should be kept part of our |
74 |
> build system -- eclasses, ebuilds or just some specificities like |
75 |
> libdir or pkg-config path switching. |
76 |
|
77 |
Maybe, but that would involve perfectly working setups being "broken". |
78 |
It's like packages not respecting CC being broken for cross-compiling, |
79 |
those not respecting CFLAGS being broken for multilib, etc. packages |
80 |
calling directly binaries having ABI specific output will be broken for |
81 |
multilib too (and I don't know of anyone checking for this while the |
82 |
other two have been long standing issues we tried to fix). We can fix |
83 |
this, but the fact is that we need multi-binary support for users, then |
84 |
the only choice to make is if we want to provide a wrapper so that we |
85 |
do not need to fix build systems or if we want to fix them. The latter |
86 |
is likely preferred but I do not know what kind of work it will involve. |
87 |
It'd help if tommy could provide a list of binaries he needed to wrap |
88 |
through the abiwrapper. |
89 |
|
90 |
Alexis. |