set up a bin-building machine

Message

lordalbert · Post by **lordalbert** » Sun Jun 07, 2015 2:06 pm

Hi, i have 2 gentoo machines: a notebook and a desktop. In these hot days, compiling from notebook is mad! So... i want to setup my desktop to compile pkg for my notebook.

I copied in /mnt/chrooted of my desktop a new stage3, and my idea is to chroot into that and use it as a clone of my notebook. I first upgrade/install in that chroot workspace, than (setting up portage) i upgrade/install using pkg builded on desktop.

So, after extract a stage3, i copied world file and /etc/portage (from my notebook to chrooted workspace).

The problem is: my notebook as a i5 processor, my dekstop has an (old) core2duo. In notebook, i use -march=native, equivalent to corei7-avx.

My question is: if i compile in my chroot workspace with corei7-avx -march, it should gives me some problems... right? So... is better to compile with -march=native from my desktop? the pkg will be not full-optimized for i5, but i will not problems... (i think!)
If i have a notebook with some software build with -march=corei7-avx and some software build with -march relative to core2duo... could give me some problems?!

If you have any suggestion, thank you!

Post by **John R. Graham** » Sun Jun 07, 2015 2:14 pm

If the desktop and laptop are both set up for the same word size (i.e., both 32-bit or both 64-bit) then you can just set the CFLAGS in your chroot to match your laptop and compile to your heart's content. Otherwise, you'll need to set up a crossdev toolchain in the chroot. You can also go the distcc route just exporting the actual compiling to your desktop. See the Distcc/Cross-Compiling article on the Wiki, which contains extractable advice on all three variations. In particular, there is advice to get gcc to show you the exact CFLAGS to set for a particular CPU as detected by gcc's -march=native command line option.

- John

lordalbert · Post by **lordalbert** » Sun Jun 07, 2015 2:19 pm

they are both x86_64

Ok, i start compiling!

krinn · Post by **krinn** » Sun Jun 07, 2015 5:50 pm

when using distcc (even when not crosscompiling) or when crosscompiling, every ebuild make sure to not run anything that is build.

that's something you will not have, and that's something that will gave you ugly, but ugly surprise, as at least one of them is gcc (stage2 is xgcc build gcc and it will do it with native)

so better do the things right, use a cross compiler or your fate is doom.

lordalbert · Post by **lordalbert** » Sun Jun 07, 2015 6:20 pm

ok, so i just need to set the system for crosscompiling?

Now, i have some errors in emerging various pkg. Could it be the cause, or i have other problems?

EDIT: I found only distcc howto that speak about crosscompiling. I don't want to use distcc, but create bin-pkg only on a separate machine, and install binary in my notebook. How could I set crosscompiling in this case?

EDIT: I have an idea! If i run my build-system not in chroot but in a virtual machine (like virtualbox)... can i avoid crosscompile and simplify the work?

Post by **NeddySeagoon** » Sun Jun 07, 2015 8:56 pm

lordalbert,

It you want to build optimised i5 code on a core2duo you must do so in a way that does not require the core2duo to execute any code intended for the i5.
That rules out a chroot and most Virtual Machines, as they run everything on the host processor. Using QEMU to emulate the CPU in software is several 100 times slower that a real processor, so while it works, its less that ideal.

If you still want the core2duo to produce optimised i5 packages, you need to use a cross compiler of some sort.
Cross distcc will work as all the i5 code execution stays on the i5. The core2duo builds it and passes it to the i5.

A pure cross environment way work. A few odd build systems want to generate then run code in the course of the build. When you are cross compiling for say a Raspberry Pi (ARM) you can hear the crash. With a core2duo building for an i5, there is a chance you won't hit the illegal instruction error.
A mix of cross distcc and pure cross compiling can be used too.

krinn · Post by **krinn** » Sun Jun 07, 2015 9:23 pm

I think you have two easy choice:
1/ using distcc, you don't even need a cross-compiling distcc as both arch are the same, just using distcc will prevent ebuild to either been build on the core2 if it's not doable (that's it, other distcc users and devs have done the work for you already) or build it on the core2 while aiming for the i5 code if it's doable. While the cases where distcc cannot be use would be problematic as the build will be done with the i5 only, it's still "few" cases. Alas in this few cases, there's gcc.

2/ another perfect solution would just be you accept the core2 is only building core2 valid code, because the i5 will have no problem running it. It might appears poor to loose some i5 optimizations, but in your case, it's balance by the fact the i5 will have hard time to build it alone, and having an i5 running core2 code would be better than anything as it's something it didn't had build itself. And you may reoptimize them in winter when your i5 could handle it.