From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B8C25198005 for ; Mon, 4 Mar 2013 10:03:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B33F5E06C8; Mon, 4 Mar 2013 10:02:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B1D82E06B4 for ; Mon, 4 Mar 2013 10:02:47 +0000 (UTC) Received: from portable (AMontpellier-651-1-453-97.w81-251.abo.wanadoo.fr [81.251.252.97]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id C9C4233DE3E; Mon, 4 Mar 2013 10:02:45 +0000 (UTC) Date: Mon, 4 Mar 2013 11:02:40 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Cc: mgorny@gentoo.org, tommy@gentoo.org Subject: Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs Message-ID: <20130304110240.75f9d12e@portable> In-Reply-To: <20130303232503.3ad202e5@pomiocik.lan> References: <20130303000230.13fea8b8@pomiocik.lan> <51334A02.40705@gentoo.org> <20130303162404.5488ada7@portable> <5133709F.4020909@gentoo.org> <20130303171022.101be411@portable> <51337A06.20400@gentoo.org> <20130303175826.24a7f0c1@pomiocik.lan> <20130303181812.3d6b5cbe@portable> <20130303232503.3ad202e5@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e53a4d88-2307-4da7-8ff4-3f3290de4c70 X-Archives-Hash: c60e943e4475194b4c2b291a77def230 On Sun, 3 Mar 2013 23:25:03 +0100 Micha=C5=82 G=C3=B3rny wrote: > On Sun, 3 Mar 2013 18:18:12 +0100 > Alexis Ballier wrote: >=20 > > On Sun, 3 Mar 2013 17:58:26 +0100 > > Micha=C5=82 G=C3=B3rny wrote: > >=20 > > > What do we need that wrapper for? What does the wrapper do? Does > > > it just rely on custom 'ABI' variable? > >=20 > > yes -- it must perform some checks though. >=20 > What kind of checks? you are called with ABI=3Dsth argv[0] =3D your name if argv[0] =3D abiwrapper -> print some information and exit getenv ABI -> if nothing then set ABI=3D$DEFAULT_ABI (hardcoded at buildtime of the wrapper) execvp(argv[0]_$ABI, argv) if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI python-wrapper.c is very likely to have such a logic already. btw, IMHO ABI is a too common name for such a variable, I'd better name it something like _GENTOO_MULTILIB_ABI so that collisions are much less likely. > > > Or maybe should it try to detect > > > whether it was called by a 64- or 32-bit app? > >=20 > > 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_ >=20 > 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? That's why I asked for examples :) qmake may do it, I don't think its sane, but that's life for now. having glxinfo for each abi is useful from a user perspective (it does not need the wrapper a priori though) > > > What for? > >=20 > > in order to be transparent from the ebuild perspective. >=20 > 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. See it something like python-wrapper. EPYTHON=3Dpython3.2 python -> runs python3.2 :) > 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. >=20 > 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. To some extent that's what happened to python too :) As a python maintainer, you could share your thoughts on the topic. python slotting was intended to make switching between python versions easy but has been needing wrappers for the python binary. > 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. Maybe, but that would involve perfectly working setups being "broken". It's like packages not respecting CC being broken for cross-compiling, those not respecting CFLAGS being broken for multilib, etc. packages calling directly binaries having ABI specific output will be broken for multilib too (and I don't know of anyone checking for this while the other two have been long standing issues we tried to fix). We can fix this, but the fact is that we need multi-binary support for users, then the only choice to make is if we want to provide a wrapper so that we do not need to fix build systems or if we want to fix them. The latter is likely preferred but I do not know what kind of work it will involve. It'd help if tommy could provide a list of binaries he needed to wrap through the abiwrapper. Alexis.