1 |
On Sat, Jan 02, 2016 at 12:55:56PM -0600, Jc García wrote |
2 |
|
3 |
> Then why the recently introuced multilib method of bulding 32bit |
4 |
> libraries for packages that need it on 64 bit works? I don't think the |
5 |
> devs would have bothered to introudce the variable ABI_X86 and a |
6 |
> mulitib eclass just to compile a 32bit Hello World. |
7 |
> |
8 |
> I'm not trying to make a flame here, but don't blame the compiler, |
9 |
> when in this case is more likely you the user are doing something |
10 |
> wrong. |
11 |
> My guess is you are blaming the effects of CPU_FLAGS_X86 on CFLAGS. |
12 |
|
13 |
The fact that I use "no-multilib" profiles on my 64-bit machines |
14 |
probably doesn't help. The example I was using involved a manual build |
15 |
of Pale Moon from source. I manually specified in the build script... |
16 |
|
17 |
ac_add_options --enable-optimize="-O2 -march=bonnell -mfpmath=sse -pipe \ |
18 |
-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables \ |
19 |
-mmmx -msse -msse2 -mssse3 -mmovbe -mfxsr" |
20 |
|
21 |
...which are the options I use on my netbook client for outsourcing the |
22 |
build process. So the host's CPU_FLAGS_X86 setting should not be a |
23 |
problem. |
24 |
|
25 |
I'd love to be proven wrong in my contention. If you can run the |
26 |
Mozilla-like build on a 64-bit OS, and produce a 32-bit binary, that's |
27 |
the ultimate "torture-test". |
28 |
|
29 |
-- |
30 |
Walter Dnes <waltdnes@××××××××.org> |
31 |
I don't run "desktop environments"; I run useful applications |