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