1 |
Mike Frysinger wrote: |
2 |
> On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote: |
3 |
>> As I'm building the toolchain myself too, I configure it with the |
4 |
>> 32bit host triplet on each platform, usually disabling multilib. |
5 |
> |
6 |
> this doesnt make any sense to me |
7 |
|
8 |
What exactly doesn't make sense to you: |
9 |
* building the toolchain in general: |
10 |
The application is quality assured to one specific gcc version, and |
11 |
I cannot expect that exactly this one version is available on the |
12 |
target machine, especially when some specific patches are required, |
13 |
or there is no gcc available at all, or the installation is just broken. |
14 |
And sometimes I do have multiple application releases on the same |
15 |
machine, requiring different gcc versions... |
16 |
* using the 32bit host triplet: |
17 |
see below |
18 |
* or disabling multilib: |
19 |
whenever possible I'd like to avoid messing with multilib. |
20 |
|
21 |
>> But Linux "is not Unix": |
22 |
> |
23 |
> you're right, so i'm not terribly concerned with compatibility with non-Linux |
24 |
> systems. comparing the native Gentoo/Linux multilib setup to another Linux |
25 |
> multilib setup is the only useful comparison. |
26 |
|
27 |
Agreed. Although it is uncommon that Linux causes more headaches than Unix, |
28 |
especially when it is about GNU packages. |
29 |
|
30 |
>> Configuring both binutils and gcc needs to be done with: |
31 |
>> $ CC="gcc -m32" /path/to/configure --{build,host}=i686-pc-linux-gnu ... |
32 |
>> This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /lib, |
33 |
>> 64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux. |
34 |
|
35 |
> i dont get it. why does the i686-pc-linux-gnu toolchain target matter on an |
36 |
> amd64 multilib system ? the native x86_64-pc-linux-gnu toolchain should |
37 |
> already do the right thing when given -m32. |
38 |
|
39 |
It is more an administrative thing: On Unix as well as x86-linux I simply |
40 |
get 32bits from gcc. But for x86_64-linux I'm in need of an exception to |
41 |
build/use some x86_64-gcc and wrap it with -m32, because I don't want to |
42 |
force the application-maintainers to add this exception to add CFLAGS=-m32, |
43 |
which can be interpreted as "require some change to keep it unchanged". |
44 |
And it is ways easier to use --{build,host} than to create wrappers. |
45 |
|
46 |
>> Isn't the intention of multilib to have a new (64bit) system |
47 |
>> be compatible with the corresponding old (32bit) system? |
48 |
> |
49 |
> your description of "compatible" is pretty vague. ignoring /lib -> /lib64 |
50 |
> symlink (which shouldnt matter to any binaries), i'm not aware of any |
51 |
> differences off the top of my head. |
52 |
|
53 |
Well, "compatible" here means to me that when I do |
54 |
$ configure --{build,host}=i686-pc-linux-gnu |
55 |
on x86-linux, I'd like to expect this working on x86_64-linux too, as the |
56 |
"_64" can be seen as an "extension"[1] to x86 I just do not want to use. |
57 |
|
58 |
It turns out that it is the "/lib resolving to 64bit" thing only that |
59 |
causes me headaches here, which actually is distro-specific. |
60 |
|
61 |
[1] http://en.wikipedia.org/wiki/X86-64 |
62 |
|
63 |
/haubi/ |