On Sat, 9 Mar 2013 11:10:11 +0100 Alexis Ballier <aball...@gentoo.org> wrote:
> On Fri, 8 Mar 2013 17:30:10 +0100 > Michał Górny <mgo...@gentoo.org> wrote: > > > We're talking about two different tricks. > > > > 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'. > > > > 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. > > > > 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. > > > > And that's just theory. I may be missing some of the dangers. > > 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. > > 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='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. -- Best regards, Michał Górny
signature.asc
Description: PGP signature