Gentoo Archives: gentoo-dev

From: Alexis Ballier <aballier@g.o>
To: gentoo-dev@l.g.o
Cc: mgorny@g.o, tommy@g.o
Subject: Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
Date: Fri, 15 Mar 2013 10:32:48
Message-Id: 20130315113231.71a28ed9@portable
In Reply to: Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs by "Michał Górny"
1 On Sun, 10 Mar 2013 14:42:43 +0100
2 Michał Górny <mgorny@g.o> wrote:
3 > > If you consider the argv trick fragile, which is understandable, the
4 > > same wrapper idea can be used differently: If you want to wrap a
5 > > binary foo, move it to foo_${abi} and build a wrapper with hardcoded
6 > > 'foo' instead of argv[0] that you install as foo. You can even
7 > > hardcode its path and use execv instead of execvp. That would
8 > > invalidate all your above objections I think :)
9 >
10 > Well, yes. In the worst case we could go that way, although it's a bit
11 > of overkill, don't you think? While we're talking about a few programs
12 > which will actually need it, and even less which will require
13 > modification in more than one place.
14
15 You are starting to convince me a bin wrapper may not be needed. qt
16 will have to be converted to multilib at some point and we'll be able
17 to discuss if we want this or not at that point. We have a generic
18 solution (the bin wrapper) but should likely prefer the longer and more
19 difficult road of making packages more multilib-aware. Let's see the
20 outcome when we'll be at it.
21
22 > > Let alone qmake, how do you suggest dealing with *-config scripts?
23 > > Some packages are just not written with multilib in mind, or have
24 > > to maintain historical compatibility which was not, wrapping the
25 > > problematic binaries is one solution to this. I've not seen any
26 > > other solution.
27 >
28 > Choose optimal solution per-package. In case of freetype, the solution
29 > is simple enough: make multilib-aware packages use pkg-config.
30 > fontconfig does exactly that, and in the earlier version it was enough
31 > to export something like FREETYPE_CONFIG='pkg-config freetype2'
32 > (or ac_cv...).
33
34 In this case there's also cmake, and all the other build system types,
35 maybe even custom ones. pkg-config should be prefered over *-config
36 scripts in 99% of the cases I'd say; however, setting FREETYPE_CONFIG
37 isn't less of a hack than the bin wrapper if patches for using
38 pkg-config to detect freetype are not merged upstream.
39
40
41 Alexis.

Replies