| 1 |
2016-01-02 12:27 GMT-06:00 <waltdnes@××××××××.org>: |
| 2 |
> On Sat, Jan 02, 2016 at 02:56:58PM +0300, Andrew Savchenko wrote |
| 3 |
> |
| 4 |
>> For 32-bit distcc on 64-bit host there is no need to chroot or |
| 5 |
>> create VM (hey, they're hellishly slow!). Just add -m32 to your |
| 6 |
>> *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores |
| 7 |
>> {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this |
| 8 |
>> can be worked around on distcc server by forcing -m32 for each |
| 9 |
>> gcc call. |
| 10 |
> |
| 11 |
> -m32 in a 64-environment works for "Hello World". More complex code |
| 12 |
> that requires arch-specific headers and libs will have problems. |
| 13 |
Then why the recently introuced multilib method of bulding 32bit |
| 14 |
libraries for packages that need it on 64 bit works? I don't think the |
| 15 |
devs would have bothered to introudce the variable ABI_X86 and a |
| 16 |
mulitib eclass just to compile a 32bit Hello World. |
| 17 |
|
| 18 |
I'm not trying to make a flame here, but don't blame the compiler, |
| 19 |
when in this case is more likely you the user are doing something |
| 20 |
wrong. |
| 21 |
My guess is you are blaming the effects of CPU_FLAGS_X86 on CFLAGS. |
Archives