| 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/ |
Archives