[gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

  My situation...

* I've dug up my ancient netbook, and got Gentoo re-installed on it
* The cpu is a dual-core Intel(R) Atom(TM) CPU Z520
* It's 32-bit only; YES!
* Compiling just the Seamonkey binary (ignoring its dependancies) took
  14 hours

  I obviously want to offload compiling to another machine.  As per the
subject, will a 64-bit no-multilb install be able to cross compile
32-bit code?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On Wednesday, March 18, 2015 9:56:12 PM Walter Dnes wrote:
>   My situation...
> 
> * I've dug up my ancient netbook, and got Gentoo re-installed on it
> * The cpu is a dual-core Intel(R) Atom(TM) CPU Z520
> * It's 32-bit only; YES!
> * Compiling just the Seamonkey binary (ignoring its dependancies) took
>   14 hours
> 
>   I obviously want to offload compiling to another machine.  As per the
> subject, will a 64-bit no-multilb install be able to cross compile
> 32-bit code?

I've done it with distcc by adding the -m32 option to cflags. I used a script 
(named after the compiler on the gentoo box) to call the compiler with the -
m32 flag and placed on the PATH environment (just for the distccd service) 
before anything else and it worked. I got a 64 bit arch box to compile for a 
32 bit gentoo (not nearly as fast as compiling locally on the arch box but 
much faster than the gentoo box). It should work similarly with other cross-
compile scenarios.


-- 
Fernando Rodriguez

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Wed, Mar 18, 2015 at 10:27:05PM -0400, Fernando Rodriguez wrote
> On Wednesday, March 18, 2015 9:56:12 PM Walter Dnes wrote:
> >   My situation...
> > 
> > * I've dug up my ancient netbook, and got Gentoo re-installed on it
> > * The cpu is a dual-core Intel(R) Atom(TM) CPU Z520
> > * It's 32-bit only; YES!
> > * Compiling just the Seamonkey binary (ignoring its dependancies) took
> >   14 hours
> > 
> >   I obviously want to offload compiling to another machine.  As per the
> > subject, will a 64-bit no-multilb install be able to cross compile
> > 32-bit code?
> 
> I've done it with distcc by adding the -m32 option to cflags. I used a script 
> (named after the compiler on the gentoo box) to call the compiler with the -
> m32 flag and placed on the PATH environment (just for the distccd service) 
> before anything else and it worked. I got a 64 bit arch box to compile for a 
> 32 bit gentoo (not nearly as fast as compiling locally on the arch box but 
> much faster than the gentoo box). It should work similarly with other cross-
> compile scenarios.

  Thanks.  I'll probably be back with a bunch of questions.  As a matter
of fact, I already have one.  The docs say that it does not work if the
"-march=native" cflag is used.  It says to use the output of...

gcc -march=native -E -v - </dev/null 2>&1 | grep cc1

...omitting "/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/cc1 -E -quiet -v -"
I presume.  So on the 64-bit host, I would go from...

CFLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"

...to...

CFLAGS="-O2 -march=core2 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2 -fstack-protector -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"

  And on the target (netbook), I'd go to...

CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables" 

  Is that correct (assuming that's my output)?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

On Thursday, March 19, 2015 12:20:26 AM Walter Dnes wrote:
> On Wed, Mar 18, 2015 at 10:27:05PM -0400, Fernando Rodriguez wrote
> > On Wednesday, March 18, 2015 9:56:12 PM Walter Dnes wrote:
> > >   My situation...
> > > 
> > > * I've dug up my ancient netbook, and got Gentoo re-installed on it
> > > * The cpu is a dual-core Intel(R) Atom(TM) CPU Z520
> > > * It's 32-bit only; YES!
> > > * Compiling just the Seamonkey binary (ignoring its dependancies) took
> > >   14 hours
> > > 
> > >   I obviously want to offload compiling to another machine.  As per the
> > > subject, will a 64-bit no-multilb install be able to cross compile
> > > 32-bit code?
> > 
> > I've done it with distcc by adding the -m32 option to cflags. I used a 
script 
> > (named after the compiler on the gentoo box) to call the compiler with the 
-
> > m32 flag and placed on the PATH environment (just for the distccd service) 
> > before anything else and it worked. I got a 64 bit arch box to compile for 
a 
> > 32 bit gentoo (not nearly as fast as compiling locally on the arch box but 
> > much faster than the gentoo box). It should work similarly with other 
cross-
> > compile scenarios.
> 
>   Thanks.  I'll probably be back with a bunch of questions.  As a matter
> of fact, I already have one.  The docs say that it does not work if the
> "-march=native" cflag is used.  It says to use the output of...
> 
> gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
> 
> ...omitting "/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/cc1 -E -quiet -v -"
> I presume.  So on the 64-bit host, I would go from...
> 
> CFLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe -fno-
unwind-tables -fno-asynchronous-unwind-tables"
> 
> ...to...
> 
> CFLAGS="-O2 -march=core2 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-
popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-
tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -
mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -
mno-xsave -mno-xsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 
--param l2-cache-size=2048 -mtune=core2 -fstack-protector -mfpmath=sse -fomit-
frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
> 
>   And on the target (netbook), I'd go to...
> 
> CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul -mno-
popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-
tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -
mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -
mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line-size=64 
--param l2-cache-size=512 -mtune=atom -fstack-protector -mfpmath=sse -fomit-
frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables" 
> 
>   Is that correct (assuming that's my output)?

The CFLAGS on the host won't be used so you don't need to change them. Now on 
the host create scripts with the exact full name of the compiler on the target 
and make distccd can find them (either put them on /usr/bin or make sure to add 
it's path to the PATH environment var for distccd, if you're using openrc I'm 
not sure if the init scripts allow it so you may have to start it manually or 
modify the scripts) and have them exec gcc with the -m32 switch. Make sure you 
have the same version of gcc selected on both boxes.


-- 
Fernando Rodriguez

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Mike Gilbert]

On Thu, Mar 19, 2015 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>
>   Is that correct (assuming that's my output)?
>

I should warn you against including all of those -mno-xxx flags. This
has been known to break the build process for packages like chromium,
which always wants to build with SSE4 support and toggles it off at
runtime. Passing -mno-sse4.1 causes a build failure as it tries to use
macros that are not defined.

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

On Saturday, March 21, 2015 8:46:10 AM Mike Gilbert wrote:
> On Thu, Mar 19, 2015 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> > CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul -
mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -
mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-
hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr 
-mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line-
size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector -mfpmath=sse -
fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
> >
> >   Is that correct (assuming that's my output)?
> >
> 
> I should warn you against including all of those -mno-xxx flags. This
> has been known to break the build process for packages like chromium,
> which always wants to build with SSE4 support and toggles it off at
> runtime. Passing -mno-sse4.1 causes a build failure as it tries to use
> macros that are not defined.
> 

Isn't it possible that removing it for all packages would cause a more subtle 
problem with another faulty ebuild (like a program crashing due to an illegal 
instruction)?

-- 
Fernando Rodriguez

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Mike Gilbert]

On Sat, Mar 21, 2015 at 3:52 PM, Fernando Rodriguez
<frodriguez.developer@outlook.com> wrote:
> On Saturday, March 21, 2015 8:46:10 AM Mike Gilbert wrote:
>> On Thu, Mar 19, 2015 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> > CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul -
> mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -
> mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-
> hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr
> -mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line-
> size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector -mfpmath=sse -
> fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>> >
>> >   Is that correct (assuming that's my output)?
>> >
>>
>> I should warn you against including all of those -mno-xxx flags. This
>> has been known to break the build process for packages like chromium,
>> which always wants to build with SSE4 support and toggles it off at
>> runtime. Passing -mno-sse4.1 causes a build failure as it tries to use
>> macros that are not defined.
>>
>
> Isn't it possible that removing it for all packages would cause a more subtle
> problem with another faulty ebuild (like a program crashing due to an illegal
> instruction)?

Passing -march=atom should be sufficient to ensure that you don't get
any illegal instructions. The -mno-XXX flags are redundant, and MOSTLY
harmless.

In the case of chromium, the build system adds -msse4.1 for specific
files (just the ones using SSE4.1 instructons). When you have
-mno-sse4.1, this takes precedence and the build fails.

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Mike Gilbert]

On Sun, Mar 22, 2015 at 10:03 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Sat, Mar 21, 2015 at 3:52 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
>> On Saturday, March 21, 2015 8:46:10 AM Mike Gilbert wrote:
>>> On Thu, Mar 19, 2015 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>>> > CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul -
>> mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -
>> mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-
>> hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr
>> -mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line-
>> size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector -mfpmath=sse -
>> fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>>> >
>>> >   Is that correct (assuming that's my output)?
>>> >
>>>
>>> I should warn you against including all of those -mno-xxx flags. This
>>> has been known to break the build process for packages like chromium,
>>> which always wants to build with SSE4 support and toggles it off at
>>> runtime. Passing -mno-sse4.1 causes a build failure as it tries to use
>>> macros that are not defined.
>>>
>>
>> Isn't it possible that removing it for all packages would cause a more subtle
>> problem with another faulty ebuild (like a program crashing due to an illegal
>> instruction)?
>
> Passing -march=atom should be sufficient to ensure that you don't get
> any illegal instructions. The -mno-XXX flags are redundant, and MOSTLY
> harmless.
>
> In the case of chromium, the build system adds -msse4.1 for specific
> files (just the ones using SSE4.1 instructons). When you have
> -mno-sse4.1, this takes precedence and the build fails.

To put it another way: back in the day before gcc -march=native,
nobody would have told you to put a bunch of -mno-xxx flags in your
global CFLAGS. They would have told you to find the -march setting
most appropriate for your processor.

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

On Sunday, March 22, 2015 10:03:01 AM Mike Gilbert wrote:
> On Sat, Mar 21, 2015 at 3:52 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
> > On Saturday, March 21, 2015 8:46:10 AM Mike Gilbert wrote:
> >> On Thu, Mar 19, 2015 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> 
wrote:
> >> > CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul -
> > mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-
bmi2 -
> > mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -
mno-
> > hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -
mfxsr
> > -mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line-
> > size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector -
mfpmath=sse -
> > fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-
tables"
> >> >
> >> >   Is that correct (assuming that's my output)?
> >> >
> >>
> >> I should warn you against including all of those -mno-xxx flags. This
> >> has been known to break the build process for packages like chromium,
> >> which always wants to build with SSE4 support and toggles it off at
> >> runtime. Passing -mno-sse4.1 causes a build failure as it tries to use
> >> macros that are not defined.
> >>
> >
> > Isn't it possible that removing it for all packages would cause a more 
subtle
> > problem with another faulty ebuild (like a program crashing due to an 
illegal
> > instruction)?
> 
> Passing -march=atom should be sufficient to ensure that you don't get
> any illegal instructions. The -mno-XXX flags are redundant, and MOSTLY
> harmless.
> 
> In the case of chromium, the build system adds -msse4.1 for specific
> files (just the ones using SSE4.1 instructons). When you have
> -mno-sse4.1, this takes precedence and the build fails.
> 

Thanks for explaining.

-- 
Fernando Rodriguez

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

On Sunday, March 22, 2015 10:03:01 AM Mike Gilbert wrote:
> On Sat, Mar 21, 2015 at 3:52 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
> > On Saturday, March 21, 2015 8:46:10 AM Mike Gilbert wrote:
> >> On Thu, Mar 19, 2015 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> 
wrote:
> >> > CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul -
> > mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-
bmi2 -
> > mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -
mno-
> > hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -
mfxsr
> > -mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line-
> > size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector -
mfpmath=sse -
> > fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-
tables"
> >> >
> >> >   Is that correct (assuming that's my output)?
> >> >
> >>
> >> I should warn you against including all of those -mno-xxx flags. This
> >> has been known to break the build process for packages like chromium,
> >> which always wants to build with SSE4 support and toggles it off at
> >> runtime. Passing -mno-sse4.1 causes a build failure as it tries to use
> >> macros that are not defined.
> >>
> >
> > Isn't it possible that removing it for all packages would cause a more 
subtle
> > problem with another faulty ebuild (like a program crashing due to an 
illegal
> > instruction)?
> 
> Passing -march=atom should be sufficient to ensure that you don't get
> any illegal instructions. The -mno-XXX flags are redundant, and MOSTLY
> harmless.
 
You got me curious as to why they're there being redundant and I think I found 
out why.

I looked at the code (gcc/config/i386/driver-i386.c) and there is a very slim 
chance that the -march reported by gcc when using -march=native will not be 
the most appropriate. In some cases it's guessed based on the features 
reported by the CPU but on other cases it trusts the model number and Intel 
lists several Atom server CPUs and SoCs with no extensions at all (I have no 
idea what they report themselves like or if their specs are right). All the -
mxxx and -mno-xxx flags are determined by the features reported by the CPU so 
no chance of error there (save from a CPU bug).

I guess gcc devs are careful when using the model numbers (Intel lists 3 for 
Atoms, gcc uses only two so that may account for the models I mentioned) but 
the chance of error is there. The -mno-xxx flags would safeguard against it.

-- 
Fernando Rodriguez

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Sun, Mar 22, 2015 at 09:25:53PM -0400, Fernando Rodriguez wrote
 
> I guess gcc devs are careful when using the model numbers (Intel
> lists 3 for Atoms, gcc uses only two so that may account for the
> models I mentioned) but the chance of error is there. The -mno-xxx
> flags would safeguard against it.

  I have one of the earliest Atom chips.  Some people have a hard time
believing this, but it's a 32-bit-only chip;  a couple of lines from
/proc/cpuinfo

model name      : Intel(R) Atom(TM) CPU Z520   @ 1.33GHz
address sizes   : 32 bits physical, 32 bits virtual

  Intel gives the CPU's specs at...

http://ark.intel.com/products/35466/Intel-Atom-Processor-Z520-512K-Cache-1_33-GHz-533-MHz-FSB

...where it specifically says...

Intel 64 # No

  I want to make absolutely certain that "illegal instructions" are not
compiled for it.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Mike Gilbert]

On Mon, Mar 23, 2015 at 9:51 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sun, Mar 22, 2015 at 09:25:53PM -0400, Fernando Rodriguez wrote
>
>> I guess gcc devs are careful when using the model numbers (Intel
>> lists 3 for Atoms, gcc uses only two so that may account for the
>> models I mentioned) but the chance of error is there. The -mno-xxx
>> flags would safeguard against it.
>
>   I have one of the earliest Atom chips.  Some people have a hard time
> believing this, but it's a 32-bit-only chip;  a couple of lines from
> /proc/cpuinfo
>
> model name      : Intel(R) Atom(TM) CPU Z520   @ 1.33GHz
> address sizes   : 32 bits physical, 32 bits virtual
>
>   Intel gives the CPU's specs at...
>
> http://ark.intel.com/products/35466/Intel-Atom-Processor-Z520-512K-Cache-1_33-GHz-533-MHz-FSB
>
> ...where it specifically says...
>
> Intel 64 # No
>
>   I want to make absolutely certain that "illegal instructions" are not
> compiled for it.

You will probably need to add -m32 to CFLAGS to avoid building 64-bit
objects on the 64-bit machine.

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

On Monday, March 23, 2015 6:18:46 PM Mike Gilbert wrote:
> On Mon, Mar 23, 2015 at 9:51 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> > On Sun, Mar 22, 2015 at 09:25:53PM -0400, Fernando Rodriguez wrote
> >
> >> I guess gcc devs are careful when using the model numbers (Intel
> >> lists 3 for Atoms, gcc uses only two so that may account for the
> >> models I mentioned) but the chance of error is there. The -mno-xxx
> >> flags would safeguard against it.
> >
> >   I have one of the earliest Atom chips.  Some people have a hard time
> > believing this, but it's a 32-bit-only chip;  a couple of lines from
> > /proc/cpuinfo
> >
> > model name      : Intel(R) Atom(TM) CPU Z520   @ 1.33GHz
> > address sizes   : 32 bits physical, 32 bits virtual
> >
> >   Intel gives the CPU's specs at...
> >
> > http://ark.intel.com/products/35466/Intel-Atom-Processor-Z520-512K-Cache-1_33-GHz-533-MHz-FSB
> >
> > ...where it specifically says...
> >
> > Intel 64 # No
> >
> >   I want to make absolutely certain that "illegal instructions" are not
> > compiled for it.
> 
> You will probably need to add -m32 to CFLAGS to avoid building 64-bit
> objects on the 64-bit machine.
> 

Your CPU is an example of what I'm saying, not just because it doesn't have 64 
bit extensions but because it doesn't have MMX (at least according to the 
specs) and according to the GCC manual -march=atom means: "Intel Atom CPU with 
64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set 
support." So I guess it's more common than I thought.

So you may also want to add -mno-mmx to be sure. GCC does check for mmx but it 
doesn't not use it on the output (probably a bug?).


-- 
Fernando Rodriguez

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Mike Gilbert]

On Mon, Mar 23, 2015 at 6:41 PM, Fernando Rodriguez
<frodriguez.developer@outlook.com> wrote:
> On Monday, March 23, 2015 6:18:46 PM Mike Gilbert wrote:
>> On Mon, Mar 23, 2015 at 9:51 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> > On Sun, Mar 22, 2015 at 09:25:53PM -0400, Fernando Rodriguez wrote
>> >
>> >> I guess gcc devs are careful when using the model numbers (Intel
>> >> lists 3 for Atoms, gcc uses only two so that may account for the
>> >> models I mentioned) but the chance of error is there. The -mno-xxx
>> >> flags would safeguard against it.
>> >
>> >   I have one of the earliest Atom chips.  Some people have a hard time
>> > believing this, but it's a 32-bit-only chip;  a couple of lines from
>> > /proc/cpuinfo
>> >
>> > model name      : Intel(R) Atom(TM) CPU Z520   @ 1.33GHz
>> > address sizes   : 32 bits physical, 32 bits virtual
>> >
>> >   Intel gives the CPU's specs at...
>> >
>> > http://ark.intel.com/products/35466/Intel-Atom-Processor-Z520-512K-Cache-1_33-GHz-533-MHz-FSB
>> >
>> > ...where it specifically says...
>> >
>> > Intel 64 # No
>> >
>> >   I want to make absolutely certain that "illegal instructions" are not
>> > compiled for it.
>>
>> You will probably need to add -m32 to CFLAGS to avoid building 64-bit
>> objects on the 64-bit machine.
>>
>
> Your CPU is an example of what I'm saying, not just because it doesn't have 64
> bit extensions but because it doesn't have MMX (at least according to the
> specs) and according to the GCC manual -march=atom means: "Intel Atom CPU with
> 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set
> support." So I guess it's more common than I thought.
>
> So you may also want to add -mno-mmx to be sure. GCC does check for mmx but it
> doesn't not use it on the output (probably a bug?).
>

It's much more likely that Intel's website doesn't bother including
MMX because it is so damn old that nobody cares.

/proc/cpuinfo would be a more reliable source of data.

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

On Monday, March 23, 2015 6:48:39 PM Mike Gilbert wrote:
> On Mon, Mar 23, 2015 at 6:41 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
> > On Monday, March 23, 2015 6:18:46 PM Mike Gilbert wrote:
> >> On Mon, Mar 23, 2015 at 9:51 PM, Walter Dnes <waltdnes@waltdnes.org> 
wrote:
> >> > On Sun, Mar 22, 2015 at 09:25:53PM -0400, Fernando Rodriguez wrote
> >> >
> >> >> I guess gcc devs are careful when using the model numbers (Intel
> >> >> lists 3 for Atoms, gcc uses only two so that may account for the
> >> >> models I mentioned) but the chance of error is there. The -mno-xxx
> >> >> flags would safeguard against it.
> >> >
> >> >   I have one of the earliest Atom chips.  Some people have a hard time
> >> > believing this, but it's a 32-bit-only chip;  a couple of lines from
> >> > /proc/cpuinfo
> >> >
> >> > model name      : Intel(R) Atom(TM) CPU Z520   @ 1.33GHz
> >> > address sizes   : 32 bits physical, 32 bits virtual
> >> >
> >> >   Intel gives the CPU's specs at...
> >> >
> >> > http://ark.intel.com/products/35466/Intel-Atom-Processor-Z520-512K-Cache-1_33-GHz-533-MHz-FSB
> >> >
> >> > ...where it specifically says...
> >> >
> >> > Intel 64 # No
> >> >
> >> >   I want to make absolutely certain that "illegal instructions" are not
> >> > compiled for it.
> >>
> >> You will probably need to add -m32 to CFLAGS to avoid building 64-bit
> >> objects on the 64-bit machine.
> >>
> >
> > Your CPU is an example of what I'm saying, not just because it doesn't 
have 64
> > bit extensions but because it doesn't have MMX (at least according to the
> > specs) and according to the GCC manual -march=atom means: "Intel Atom CPU 
with
> > 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set
> > support." So I guess it's more common than I thought.
> >
> > So you may also want to add -mno-mmx to be sure. GCC does check for mmx 
but it
> > doesn't not use it on the output (probably a bug?).
> >
> 
> It's much more likely that Intel's website doesn't bother including
> MMX because it is so damn old that nobody cares.
> 
> /proc/cpuinfo would be a more reliable source of data.
> 

I agree that's very likely, that's why I said if the specs are right...
This one doesn't list any SIMD extensions at all:
http://ark.intel.com/products/85475/Intel-Atom-x7-Z8700-Processor-2M-Cache-up-to-2_40-GHz


-- 
Fernando Rodriguez

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Mon, Mar 23, 2015 at 06:41:31PM -0400, Fernando Rodriguez wrote

> Your CPU is an example of what I'm saying, not just because it
> doesn't have 64 bit extensions but because it doesn't have MMX
> (at least according to the specs) and according to the GCC manual
> -march=atom means: "Intel Atom CPU with 64-bit extensions, MOVBE,
> MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support." So I guess
> it's more common than I thought.
> 
> So you may also want to add -mno-mmx to be sure. GCC does check for
> mmx but it doesn't not use it on the output (probably a bug?).

  According to /proc/cpuinfo, it does have mmx
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl
vmx est tm2 ssse3 xtpr pdcm movbe lahf_lm dtherm tpr_shadow vnmi
flexpriority

  And while we're at it...

[aa1][root][~] cpuinfo2cpuflags-x86 
CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Mon, Mar 23, 2015 at 06:18:46PM -0400, Mike Gilbert wrote

> You will probably need to add -m32 to CFLAGS to avoid building 64-bit
> objects on the 64-bit machine.

  How could i686-pc-linux-gnu-gcc build 64-bit stuff in the first place?
I followed the instructions, and ran the following on the host 64-bit
machine...

[d531][root][~] crossdev -t -S i686-pc-linux-gnu

[d531][root][~] i686-pc-linux-gnu-gcc --version
i686-pc-linux-gnu-gcc (Gentoo 4.9.2 p1.2, pie-0.6.2) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[d531][root][~] echo 'int main(){return 0;}' > ctest.c
[d531][root][~] i686-pc-linux-gnu-gcc -Wall ctest.c -o ctest
[d531][root][~] file ctest
ctest: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux
2.6.32, not stripped

  Here's how far I've gotten with the setup.  Let me know if I'm missing
anything...

=========================================================================

On the host; 64-bit Gentoo on Core2; IP address 192.168.123.251

# emerge crossdev

# crossdev -t -S i686-pc-linux-gnu

# emerge distcc

edit /etc/conf.d/distccd to indicate allowed client(s).  Change the
DISTCCD_OPTS line to...

DISTCCD_OPTS="--port 3632 --log-level notice --log-file /var/log/distccd.log -N 15 --allow 192.168.123.253

get distccd service running now and every boot up (OpenRC)...

# rc-update add distccd default

# rc-service distccd start

  I believe it's OK to leave "-march=native" in the host's make.conf

=========================================================================

  On the client; underpowered ancient 32-bit Atom netbook; 192.168.123.253

# emerge distcc

specify host(s)

# /usr/bin/distcc-config --set-hosts "192.168.123.251"

This modifies /etc/distcc/hosts

In make.conf make the following changes

MAKEOPTS="-j1 -l2"

add "distcc distcc-pump" to FEATURES variable

  Replace "-march=native" in CFLAGS with output of...
# gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | perl -pe 's/ -mno-\S+//g; s/^.* - //g;'

  Note that the distcc wiki page gives different instructions here than
the crossdev wiki page.  The command goes out of its way to remove the
"-mno-<whatever>" compiler flags.  This results in (one long line)...

CFLAGS="-O2 -march=atom -msahf -mmovbe -mfxsr --param l1-cache-size=24
--param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=atom
-fstack-protector -mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables"

Note that I include "-mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables" myself.

=========================================================================

  Now for the questions...
1) https://wiki.gentoo.org/wiki/Distcc#Using_distcc_with_automake
mentions adding...

export PATH="/usr/lib/ccache/bin:/usr/lib/distcc/bin:${PATH}"

...to /etc/env.d/  Is this necessary for Portage/emerge/etc, or is
"automake" something separate?  (You can tell I'm not a programmer, let
alone a developer.)

2) The docs mention running emerge on the client with the command...

# pump emerge -u world

Is that all there is, or am I missing something?  Does it
"automagically" install properly?  Can I assume that...

a) The "pump" command does the lookup in /etc/distcc/hosts for the
appropriate server

b) The line...

CHOST="i686-pc-linux-gnu"

...in the client's make.conf is sufficient to tell emerge to use
"/usr/bin/i686-pc-linux-gnu-gcc" on the host and not "/usr/bin/gcc"?

3) Is this supposed to happen on the host...

=====================================================
[d531][waltdnes][~] gcc-config -l
 [1] i686-pc-linux-gnu-4.9.2 *

 [2] x86_64-pc-linux-gnu-4.8.3 *
=====================================================

Note that the asterisk after "x86_64-pc-linux-gnu-4.8.3" is green.

4) Is the command...

# DISTCC_DIR="" distccmon-text 5
  Or:
# DISTCC_DIR="" distccmon-gnome

...supposed to be run from a seprate terminal?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Mike Gilbert]

On Tue, Mar 24, 2015 at 3:17 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Mon, Mar 23, 2015 at 06:18:46PM -0400, Mike Gilbert wrote
>
>> You will probably need to add -m32 to CFLAGS to avoid building 64-bit
>> objects on the 64-bit machine.
>
>   How could i686-pc-linux-gnu-gcc build 64-bit stuff in the first place?
> I followed the instructions, and ran the following on the host 64-bit
> machine...
>

I assumed you were using the x86_64 toolchain. If you have built a
dedicated i686 toolchain, my comment does not apply.

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

On Tuesday, March 24, 2015 3:17:55 AM Walter Dnes wrote:
> On Mon, Mar 23, 2015 at 06:18:46PM -0400, Mike Gilbert wrote
> 
> > You will probably need to add -m32 to CFLAGS to avoid building 64-bit
> > objects on the 64-bit machine.
> 
>   How could i686-pc-linux-gnu-gcc build 64-bit stuff in the first place?
> I followed the instructions, and ran the following on the host 64-bit
> machine...
> 
> [d531][root][~] crossdev -t -S i686-pc-linux-gnu
> 
> [d531][root][~] i686-pc-linux-gnu-gcc --version
> i686-pc-linux-gnu-gcc (Gentoo 4.9.2 p1.2, pie-0.6.2) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> [d531][root][~] echo 'int main(){return 0;}' > ctest.c
> [d531][root][~] i686-pc-linux-gnu-gcc -Wall ctest.c -o ctest
> [d531][root][~] file ctest
> ctest: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux
> 2.6.32, not stripped
> 
>   Here's how far I've gotten with the setup.  Let me know if I'm missing
> anything...
> 
> =========================================================================
> 
> On the host; 64-bit Gentoo on Core2; IP address 192.168.123.251
> 
> # emerge crossdev
> 
> # crossdev -t -S i686-pc-linux-gnu
> 
> # emerge distcc
> 
> edit /etc/conf.d/distccd to indicate allowed client(s).  Change the
> DISTCCD_OPTS line to...
> 
> DISTCCD_OPTS="--port 3632 --log-level notice --log-file /var/log/distccd.log 
-N 15 --allow 192.168.123.253
> 
> get distccd service running now and every boot up (OpenRC)...
> 
> # rc-update add distccd default
> 
> # rc-service distccd start
> 
>   I believe it's OK to leave "-march=native" in the host's make.conf
> 
> =========================================================================
> 
>   On the client; underpowered ancient 32-bit Atom netbook; 192.168.123.253
> 
> # emerge distcc
> 
> specify host(s)
> 
> # /usr/bin/distcc-config --set-hosts "192.168.123.251"
> 
> This modifies /etc/distcc/hosts
> 
> In make.conf make the following changes
> 
> MAKEOPTS="-j1 -l2"
> 
> add "distcc distcc-pump" to FEATURES variable
> 
>   Replace "-march=native" in CFLAGS with output of...
> # gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | 
perl -pe 's/ -mno-\S+//g; s/^.* - //g;'
> 
>   Note that the distcc wiki page gives different instructions here than
> the crossdev wiki page.  The command goes out of its way to remove the
> "-mno-<whatever>" compiler flags.  This results in (one long line)...
> 
> CFLAGS="-O2 -march=atom -msahf -mmovbe -mfxsr --param l1-cache-size=24
> --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=atom
> -fstack-protector -mfpmath=sse -fomit-frame-pointer -pipe
> -fno-unwind-tables -fno-asynchronous-unwind-tables"
> 
> Note that I include "-mfpmath=sse -fomit-frame-pointer -pipe
> -fno-unwind-tables -fno-asynchronous-unwind-tables" myself.
> 
> =========================================================================
> 
>   Now for the questions...
> 1) https://wiki.gentoo.org/wiki/Distcc#Using_distcc_with_automake
> mentions adding...
> 
> export PATH="/usr/lib/ccache/bin:/usr/lib/distcc/bin:${PATH}"
> 
> ...to /etc/env.d/  Is this necessary for Portage/emerge/etc, or is
> "automake" something separate?  (You can tell I'm not a programmer, let
> alone a developer.)
> 
> 2) The docs mention running emerge on the client with the command...
> 
> # pump emerge -u world
> 
> Is that all there is, or am I missing something?  Does it
> "automagically" install properly?  Can I assume that...
> 
> a) The "pump" command does the lookup in /etc/distcc/hosts for the
> appropriate server
> 
> b) The line...
> 
> CHOST="i686-pc-linux-gnu"
> 
> ...in the client's make.conf is sufficient to tell emerge to use
> "/usr/bin/i686-pc-linux-gnu-gcc" on the host and not "/usr/bin/gcc"?
> 
> 3) Is this supposed to happen on the host...
> 
> =====================================================
> [d531][waltdnes][~] gcc-config -l
>  [1] i686-pc-linux-gnu-4.9.2 *
> 
>  [2] x86_64-pc-linux-gnu-4.8.3 *
> =====================================================
> 
> Note that the asterisk after "x86_64-pc-linux-gnu-4.8.3" is green.
> 
> 4) Is the command...
> 
> # DISTCC_DIR="" distccmon-text 5
>   Or:
> # DISTCC_DIR="" distccmon-gnome
> 
> ...supposed to be run from a seprate terminal?
> 

Let me know if you have any luck with pump mode, I didn't. IIRC it sort of 
worked but most compiles fell back to compiling locally so it's was actually 
slower. The rest of this post (or parts) may not apply if you do get it 
working.

I've also found that I get better performance without the -l N on MAKEPOTS and 
specifying the number of cores per host as follows:

distcc-config --set-hosts "192.168.123.251/4" 

It may not matter if you got only one host. Also change the -j N flag 
accordingly. You'll need to do some testing to find the right number, I've find 
that between 4 to 8 cores per physical core works best (for some reason varies 
between hosts). Just look for the right number, you'll know when you see the 
CPU usage maxing on the hosts during a parallel build. Keep in mind that most 
makefiles don't do a lot of parallel compiling so you need to use the monitor 
utility to check during a busy time.

Also if you're using wireless and you can connect via ethernet do that because 
you will see a LOT of traffic.

-- 
Fernando Rodriguez

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Tue, Mar 24, 2015 at 03:01:14PM -0400, Fernando Rodriguez wrote
> 
> Let me know if you have any luck with pump mode, I didn't. IIRC it
> sort of worked but most compiles fell back to compiling locally so
> it's was actually slower. The rest of this post (or parts) may not
> apply if you do get it working.
> 
> I've also found that I get better performance without the -l N on
> MAKEPOTS and specifying the number of cores per host as follows:
> 
> distcc-config --set-hosts "192.168.123.251/4" 
> 
> It may not matter if you got only one host. Also change the -j N flag
> accordingly. You'll need to do some testing to find the right number,
> I've find that between 4 to 8 cores per physical core works best (for
> some reason varies between hosts). Just look for the right number,
> you'll know when you see the CPU usage maxing on the hosts during a
> parallel build. Keep in mind that most makefiles don't do a lot of
> parallel compiling so you need to use the monitor utility to check
> during a busy time.

  Annoying discovery... crossdev is picky about the syntax...

crossdev -S -t i686-pc-linux-gnu

...builds the latest stable toolchain, which is currently gcc 4.8.3

crossdev -t -S i686-pc-linux-gnu

...does not complain about any errors... but it builds the absolute
latest toolchain, which is currently gcc 4.9.2 :(

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Tue, Mar 24, 2015 at 03:01:14PM -0400, Fernando Rodriguez wrote

> Let me know if you have any luck with pump mode, I didn't. IIRC it sort of 
> worked but most compiles fell back to compiling locally so it's was actually 
> slower.

  It appears to be working.  It took a couple of tries to get it going.
That final required change was to /etc/distcc/hosts on the client.
Apparently the required syntax for pump mode is like so

192.168.123.251,cpp,lzo

where 192.168.123.251 is the host.  "cpp" enables pump mode, and "lzo"
(for compression) is also required.  I originally ran...

emerge -pv --changed-use --deep --update @world

...on the client.  Things looked OK, so I ran

pump emerge --changed-use --deep --update @world

...and let er rip.  I don't have X fully functional on the client yet,
so I switched to another text console on the client and ran (as per
documentation).

DISTCC_DIR="" distccmon-text 5

  It spits out the occasional linefeed but no text.  However, looking at
tty12 on the *HOST* I see a bunch of stuff like...

Mar 25 00:51:39 d531 distccd[22479]: (dcc_job_summary) client: 192.168.123.253:38023 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:1548ms i686-pc-linux-gnu-gcc /var/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2/gio/gdbusintrospection.c
Mar 25 00:51:42 d531 distccd[22456]: (dcc_job_summary) client: 192.168.123.253:38024 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:930ms i686-pc-linux-gnu-gcc /var/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2/gio/gdbusmethodinvocation.c
Mar 25 00:51:45 d531 distccd[22510]: (dcc_job_summary) client: 192.168.123.253:38025 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:1092ms i686-pc-linux-gnu-gcc /var/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2/gio/gdbusserver.c
Mar 25 00:51:47 d531 distccd[22463]: (dcc_job_summary) client: 192.168.123.253:38026 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:299ms i686-pc-linux-gnu-gcc /var/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2/gio/gdbusinterface.c

  So it appears that the host is doing the grunt work.  Text is scrolling
on the screen of the Atom client just like a local build, but it's going
by faster than I remember in the past.

> The rest of this post (or parts) may not apply if you do get it
> working.
> 
> I've also found that I get better performance without the -l N on
> MAKEPOTS and specifying the number of cores per host as follows:
> 
> distcc-config --set-hosts "192.168.123.251/4"
> 
> It may not matter if you got only one host. Also change the -j N flag
> accordingly. You'll need to do some testing to find the right number,
> I've find that between 4 to 8 cores per physical core works best (for
> some reason varies between hosts). Just look for the right number,
> you'll know when you see the CPU usage maxing on the hosts during a
> parallel build. Keep in mind that most makefiles don't do a lot of
> parallel compiling so you need to use the monitor utility to check
> during a busy time.

  I already see an improvement.  I have plenty of room for more speedup.
CPU load on the host is stable around 0.30, so it's not being overloaded
at all.

> Also if you're using wireless and you can connect via ethernet do
> that because you will see a LOT of traffic.

  I avoid wireless at home...

1) I live in a condominium, and all channels are very busy from my
neighbours.

2) The ancient Atom netbook only does 802.11 "a" and "b" so it's not
that fast.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Wed, Mar 25, 2015 at 01:20:57AM -0400, Walter Dnes wrote
> On Tue, Mar 24, 2015 at 03:01:14PM -0400, Fernando Rodriguez wrote
> 
> > Let me know if you have any luck with pump mode, I didn't. IIRC it sort of 
> > worked but most compiles fell back to compiling locally so it's was actually 
> > slower.
> 
>   It appears to be working.  It took a couple of tries to get it going.
> That final required change was to /etc/distcc/hosts on the client.
> Apparently the required syntax for pump mode is like so
> 
> 192.168.123.251,cpp,lzo
> 
> where 192.168.123.251 is the host.  "cpp" enables pump mode, and "lzo"
> (for compression) is also required.  I originally ran...
> 
> emerge -pv --changed-use --deep --update @world
> 
> ...on the client.  Things looked OK, so I ran
> 
> pump emerge --changed-use --deep --update @world
> 
> ...and let er rip.

  An update... I see a small number of messages like so...
dev-libs:glib-2.42.2:20150325-043507.log:__________Warning: 1 pump-mode
compilation(s) failed on server, but succeeded locally.

  There are 323 modules in dev-libs/glib-2.42.2, so 322 of them
succeeded on the host, and only one had ro be done locally.  I can live
with that.  A snippet from the logfile on the host...

Mar 25 00:48:33 d531 distccd[22510]: (dcc_job_summary) client:
192.168.123.253:37977 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:382ms
i686-pc-linux-gnu-gcc
/var/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2/gio/gvolumemonitor.c
Mar 25 00:48:35 d531 distccd[22463]: (dcc_job_summary) client:
192.168.123.253:37978 COMPILE_ERROR exit:1 sig:0 core:0 ret:0 time:240ms
i686-pc-linux-gnu-gcc
/var/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2/gio/gzlibcompressor.c
Mar 25 00:49:36 d531 distccd[22479]: (dcc_job_summary) client:
192.168.123.253:37979 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:268ms
i686-pc-linux-gnu-gcc
/var/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2/gio/ggtknotificationbackend.c

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Peter Humphrey]

On Monday 23 March 2015 21:51:04 Walter Dnes wrote:

> I have one of the earliest Atom chips.  Some people have a hard time
> believing this, but it's a 32-bit-only chip;  a couple of lines from
> /proc/cpuinfo
> 
> model name      : Intel(R) Atom(TM) CPU Z520   @ 1.33GHz
> address sizes   : 32 bits physical, 32 bits virtual

I have a 32-bit Atom box too. The corresponding lines are:
model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
address sizes   : 32 bits physical, 32 bits virtual

It has two cores though, and it does have mmx according to /proc/cpuinfo.

> I want to make absolutely certain that "illegal instructions" are not
> compiled for it.

I export its packages directory via NFS to a 32-bit chroot on my workstation 
which I've set up to compile packages for it. I just have to make sure that 
/etc/portage/* is the same and it just works. Well, there are a few 
differences because the Atom box is the LAN server, but it's nearly the 
same.

-- 
Rgds
Peter.

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Sat, Mar 21, 2015 at 08:46:10AM -0400, Mike Gilbert wrote

> I should warn you against including all of those -mno-xxx flags. This
> has been known to break the build process for packages like chromium,
> which always wants to build with SSE4 support and toggles it off at
> runtime. Passing -mno-sse4.1 causes a build failure as it tries to use
> macros that are not defined.

  Weird.  The Gentoo wiki documents /etc/portage/package.env at...
https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package
for handling special cases like this.  Not every package tests at
runtime.  Leaving sse4.1 enabled could result in other packages crashing
with illegal instructions.  I don't use chromium.  But if I did, I'd use
package.env to handle it as a special case.  Chromium is plain weird
anyways.  A web browser should not require udev.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]

On Wed, Mar 18, 2015 at 09:56:12PM -0400, Walter Dnes wrote:
>   My situation...
> 
> * I've dug up my ancient netbook, and got Gentoo re-installed on it
> * The cpu is a dual-core Intel(R) Atom(TM) CPU Z520
> * It's 32-bit only; YES!
> * Compiling just the Seamonkey binary (ignoring its dependancies) took
>   14 hours
> 
>   I obviously want to offload compiling to another machine.  As per the
> subject, will a 64-bit no-multilb install be able to cross compile
> 32-bit code?

I recently did the first update after many months on my netbook, too. But I
choose the chroot path; using another linux, I tar'ed off the root
filesystem to an external disk and plugged that into my main rig. In there I
used the power of my might i5-4590 to do the upgrades. That's just that much
faster because many small packages use up minutes and minutes in the
configure and install phase. Not to mention hours spent of depend*e*ncy
calculations.

To quickly switch between building locally and via distcc (or chroot in this
case), I set up the usual march, CFLAGS, features, mirrors and such in
make.conf and then below that source my .conf file for distcc or chroot
which will override those settings. That way I only need to uncomment one
line in make.conf and I'm good to go.

Since there are different kinds of atoms, I also used the full range of
-mno- flags as given by `gcc -v -Q -march=native -O2 test.c -o test` and
because my Atom is 64 bit, but my userland 32, I manually added -m32 to
those. It went through in only a few hours for 500 packages including KDE.

The only problem I had was building the kernel. For some reason, I haven't
quite achieved coolness there yet with building it on my big machine.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any social network.

Thinking is work, work is energy and you should conserve energy.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Walter Dnes]

On Sat, Mar 28, 2015 at 12:13:53PM +0100, Frank Steinmetzger wrote

> To quickly switch between building locally and via distcc (or chroot
> in this case), I set up the usual march, CFLAGS, features, mirrors
> and such in make.conf and then below that source my .conf file for
> distcc or chroot which will override those settings. That way I only
> need to uncomment one line in make.conf and I'm good to go.

  I've got it working now, including an elegant hack that allows me to
switch at will between local and distcc builds,  without making any
changes in any config files at all.  See my post at
http://permalink.gmane.org/gmane.linux.gentoo.user/281968 for details of
how I did it.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications