Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

[Michał Górny]

On Sun, 3 Mar 2013 18:18:12 +0100
Alexis Ballier <aballier@g.o> wrote:

> On Sun, 3 Mar 2013 17:58:26 +0100
> Michał Górny <mgorny@g.o> wrote:
>
> > What do we need that wrapper for? What does the wrapper do? Does it
> > just rely on custom 'ABI' variable?
>
> yes -- it must perform some checks though.

What kind of checks?

> > Or maybe should it try to detect
> > whether it was called by a 64- or 32-bit app?
>
> this wont work: think about a build system, your shell/make will likely
> be your default abi's but may call abi-specific tools depending on what
> you build _for_ not what you build _with_

That's one side of it. The other is that if it worked, it may be
something really unexpected. Do you expect things to work differently
when called by a 32-bit program?

> > What for?
>
> in order to be transparent from the ebuild perspective.

That depends on what kind of transparency do we want. I prefer being
explicit here rather than assuming something you can't know for sure.

I think we're starting to miss the point of multilib. Multilib was
intended as a cheap way of getting things working. I believe that we
should still consider it so, and keep it in cages rather than believing
that the world is more fun with tigers jumping around.

That said, I wouldn't say that making random executables in system work
differently on ${ABI} is a way to go. That leaves the tricky imprint
of multilib visible to users who shouldn't care about it. If they do,
they're looking for multilib-portage.

The whole 'switching' part of multilib should be kept part of our build
system -- eclasses, ebuilds or just some specificities like libdir or
pkg-config path switching.

-- 
Best regards,
Michał Górny