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 3C3EB198005 for ; Mon, 4 Mar 2013 20:18:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E6268E0828; Mon, 4 Mar 2013 20:18:01 +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 E4EA7E0587 for ; Mon, 4 Mar 2013 20:18:00 +0000 (UTC) Received: from [192.168.178.20] (p548D1F97.dip.t-dialin.net [84.141.31.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tommy) by smtp.gentoo.org (Postfix) with ESMTPSA id EC5AB33DF26 for ; Mon, 4 Mar 2013 20:17:58 +0000 (UTC) Message-ID: <5135016E.20903@gentoo.org> Date: Mon, 04 Mar 2013 21:17:50 +0100 From: Thomas Sachau User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs 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> <20130304110240.75f9d12e@portable> In-Reply-To: <20130304110240.75f9d12e@portable> X-Enigmail-Version: 1.5 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2EXQTXQOAXFCFCFCLODVU" X-Archives-Salt: 5a98911e-d0ee-4255-a4ee-9b29682b88c0 X-Archives-Hash: c653c0090d6c3507530ddf61197b5bc2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EXQTXQOAXFCFCFCLODVU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alexis Ballier schrieb: > On Sun, 3 Mar 2013 23:25:03 +0100 > Micha=C5=82 G=C3=B3rny wrote: >=20 >> On Sun, 3 Mar 2013 18:18:12 +0100 >> Alexis Ballier wrote: >> >>> On Sun, 3 Mar 2013 17:58:26 +0100 >>> Micha=C5=82 G=C3=B3rny 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? >=20 > 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 >=20 >=20 > python-wrapper.c is very likely to have such a logic already. >=20 > 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. >=20 >>>> 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? >=20 > 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) >=20 >=20 >>>> 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. >=20 > See it something like python-wrapper. EPYTHON=3Dpython3.2 python -> run= s > python3.2 :) >=20 >> 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. >=20 > 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. >=20 >> 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. >=20 > 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= =2E > It'd help if tommy could provide a list of binaries he needed to wrap > through the abiwrapper. >=20 > Alexis. >=20 The actual list of packages with wrapped binaries is in the profiles dir of the multilib-portage overlay (expect this to be a minimal list, there are probably more out there we did not yet catch): dev-db/mysql abiwrapper dev-lang/perl abiwrapper dev-lang/python abiwrapper dev-lang/ruby abiwrapper dev-libs/gobject-introspection abiwrapper dev-libs/libIDL abiwrapper dev-scheme/guile abiwrapper net-libs/courier-authlib abiwrapper dev-qt/qtcore abiwrapper dev-qt/qtgui abiwrapper media-libs/fontconfig abiwrapper www-servers/apache abiwrapper x11-libs/pango abiwrapper x11-libs/gtk+ abiwrapper Keep in mind, that multilib-portage does always and unconditionally wrap *-config binaries. If you dont want to add that logic to the eclass, you need to add all packages providing such files to the list. --=20 Thomas Sachau Gentoo Linux Developer ------enig2EXQTXQOAXFCFCFCLODVU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iJwEAQECAAYFAlE1AXMACgkQG7kqcTWJkGeVuAP8DQltoI77UOLPJeQZzSN/VGbM v3G9NTyFAERoWTYqXCZMSkrBjzsKqO+EPmGUpYoUvKYb2jd+yxXEGQnVZLYhTaKC l48mF12sZQzPu4FzY829Cl6Bv64W3K1mUEhoQ2vCsDLwA9urZFK6EsyNXy3uQz9G +GtDPh5cww/Rps0cHO4= =gKIN -----END PGP SIGNATURE----- ------enig2EXQTXQOAXFCFCFCLODVU--