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 4DD35198005 for ; Sun, 10 Mar 2013 13:42:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9CE84E076B; Sun, 10 Mar 2013 13:42:18 +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 A38E5E0761 for ; Sun, 10 Mar 2013 13:42:17 +0000 (UTC) Received: from pomiocik.lan (77-255-9-250.adsl.inetia.pl [77.255.9.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 6612A33C394; Sun, 10 Mar 2013 13:42:15 +0000 (UTC) Date: Sun, 10 Mar 2013 14:42:43 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: aballier@gentoo.org, tommy@gentoo.org Subject: Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs Message-ID: <20130310144243.7d4b73b0@pomiocik.lan> In-Reply-To: <20130309111011.2e1044f3@portable> 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> <20130304214948.0d0bedf1@pomiocik.lan> <20130307172523.1f9bb381@portable> <20130308173010.4cc3a40a@pomiocik.lan> <20130309111011.2e1044f3@portable> 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: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/8d=U66vxowy5WBolbEKsDdY"; protocol="application/pgp-signature" X-Archives-Salt: 262dd985-3db7-4b2e-9f20-93ecd75eaaf0 X-Archives-Hash: 6a7288716038d15903dcabf2d7abba1c --Sig_/8d=U66vxowy5WBolbEKsDdY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 9 Mar 2013 11:10:11 +0100 Alexis Ballier wrote: > On Fri, 8 Mar 2013 17:30:10 +0100 > Micha=C5=82 G=C3=B3rny wrote: >=20 > > We're talking about two different tricks. > >=20 > > Busybox checks argv to support symlinking for a standard tool. With > > invalid argv[0], it still runs as the standard busybox binary. You can > > use it that way, the 'safe way'. > >=20 > > Unless I'm missing something, git checks argv to support symlinking > > into a few dozen tools which is optional. I doubt most of our users > > rely on that rather than using the 'git foo' syntax. > >=20 > > A wrapper needs valid argv[0] to find the actual executable. Since > > argv[0] is unlikely to contain a path, that's either reinventing some > > logic or execvp() which is a bit fragile. Plus symlink resolution > > loop. Hard links do not work at all. > >=20 > > And that's just theory. I may be missing some of the dangers. >=20 > abiwrapper with invalid argv will print a standard help message too :) Help message won't help users. We're very sorry, that won't work. Don't bother reporting it to upstream, it's Gentoo-specific hack, they'll just WONTFIX them. Feel free to report it here, we may be able to clean the mess up someday. We're basically talking about opt-out. We introduce a trick which fails in corner cases by default, hoping those cases won't happen. People start to rely on it. Then the corner case happens and we need to opt-out, and we need to fix everything that started to rely on the common case working. > I don't see why you consider execvp fragile: Don't tell me you run all > your binaries with full path. >=20 > Of course you can break it, but the question is more: Is it likely to > break in a real life situation? I think that was one of the things that were pointed out in the initial python-exec implementation. It's not broken that much as a bit inconsistent by design. As in, wrapper /usr/bin/foo-config doesn't guarantee that /usr/bin/foo-config-${ARCH} will be called (maybe something in /usr/local/bin or somewhere completely different?). > If you consider the argv trick fragile, which is understandable, the > same wrapper idea can be used differently: If you want to wrap a > binary foo, move it to foo_${abi} and build a wrapper with hardcoded > 'foo' instead of argv[0] that you install as foo. You can even hardcode > its path and use execv instead of execvp. That would invalidate all > your above objections I think :) Well, yes. In the worst case we could go that way, although it's a bit of overkill, don't you think? While we're talking about a few programs which will actually need it, and even less which will require modification in more than one place. > Let alone qmake, how do you suggest dealing with *-config scripts? > Some packages are just not written with multilib in mind, or have > to maintain historical compatibility which was not, wrapping the > problematic binaries is one solution to this. I've not seen any other > solution. Choose optimal solution per-package. In case of freetype, the solution is simple enough: make multilib-aware packages use pkg-config. fontconfig does exactly that, and in the earlier version it was enough to export something like FREETYPE_CONFIG=3D'pkg-config freetype2' (or ac_cv...). In LLVM, for example, we were considering just calling the proper config by hand. It's a single multilib package which will need it now, so it's not that problematic. If you have any specific -config scripts in mind, please point me to them. By the way, from what I recall Tommy said that llvm is basically the only -config script being actually compiled executable. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/8d=U66vxowy5WBolbEKsDdY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQJ8BAEBCgBmBQJRPI3VXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEK+PgQAMO7nSae1d5l9KP7rZidGeqY X6d9X3dcHhPy3ZLZFdGnPResNH/bFUZrFYnV0EgpRgAEd95c0bsCfHwVQ5SqEgQU OilTj72rt7FpLM0Cj4COokTGcojRh17IiwMfLZWs9aLfRcsI94U7RUGrcIJAcXzv TXWuqQBjZeHspQqdaC00fiUY/CY1gUI8aJv1cHNmrvBat7ntEW5pdVFErin0zBUH BWMXQ42cQ5J0L27RXLcFnqbXkP8UFyafay8cJ6TV8z7uqVhsIP1c/aw0qBNIw7YW 6WMDH1X0VemZWOcPs6SJAyxyeG0tpZzfQE+ebjX10kY6hTkIhnWQtxlfIDpvQh2Z 5/819l+T8C5YvMa4tX+6xAtoNFN7201BixWfCoBB8U7GtXgW8ENdoHJ+9KdY/vZ+ 1kEi9nsTWDbDc9PmGgpEf8ANduebpOck2is/RSe+Btd3+apWy8HQP4jkQDGz8fhf iRL91/d3t5OwI0fdb9gBwH0FaT+U00zYZ55Fk9YoSrjpBXD7emjBK1hr+2ZqFSUM +gtFpcIHCpM6PRr+/RU6z0IxAOczcWo1T7GzTx2sFIsaq3Kbn+dsh3INy0HXvdnB XA4RY4dIQ8Iusm63ogHviX7owtpCXQnTk+uqzOx9v28o/BsxjktSOBrKFQH/09fe qchaMCmFAmpygjEtz++r =CT87 -----END PGP SIGNATURE----- --Sig_/8d=U66vxowy5WBolbEKsDdY--