On Sun, 10 Mar 2013 14:42:43 +0100
Michał Górny <mgo...@gentoo.org> wrote:
> > 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.
You are starting to convince me a bin wrapper may not be needed. qt
will have to be converted to multilib at some point and we'll be able
to discuss if we want this or not at that point. We have a generic
solution (the bin wrapper) but should likely prefer the longer and more
difficult road of making packages more multilib-aware. Let's see the
outcome when we'll be at it.
> > 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 this case there's also cmake, and all the other build system types,
maybe even custom ones. pkg-config should be prefered over *-config
scripts in 99% of the cases I'd say; however, setting FREETYPE_CONFIG
isn't less of a hack than the bin wrapper if patches for using
pkg-config to detect freetype are not merged upstream.
Alexis.
