View previous topic :: View next topic |
Author |
Message |
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Sun Jan 03, 2021 9:14 pm Post subject: chroot |
|
|
there are two computers
pc1 with make.conf .... "CFLAGS="-O2 -pipe -march=sandybridge" (intel core i7-2600 sandybridge)
pc2 with make.conf .... "CFLAGS="-O2 -pipe -march=skylake" (intel core i5-8500 skylake)
and there are some other differences at the CPU_FLAGS_X86 like avx2 and some other....
now i will at pc1 install a gentoo system into an imagefile for pc2.
i do create an empty file, put a filesystem into it, mount it, latest stage3 and portage -files into it and than with chroot into it.
later i will put this image onto a usbdrive and copy the image to the localdisk and start the system with it at pc2.
whats about the two different make.conf files?
at the point where i enter the chroot, do i use the make.conf and gcc from the new image for pc2 or do i use the ones from pc1?
is that possible by this way or become i trouble? |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Tue Jan 05, 2021 4:12 am Post subject: |
|
|
do i need the make.conf from pc2 at pc1 if i go by chroot into the system for pc2? |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 21706
|
Posted: Tue Jan 05, 2021 4:47 pm Post subject: |
|
|
From the perspective of the processes run in the chroot, only files in the chroot exist. Running Portage in the chroot will use the /etc/portage/make.conf that is in the chroot. You can configure this one separately from the make.conf that runs your host system. When you do, take care that it generates code that works on both CPUs. You will be running chroot code first on pc1 during the build, then later on pc2 after you install. Therefore, all code in the chroot needs to use features that only exist on both CPUs. |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Thu Jan 07, 2021 4:59 am Post subject: |
|
|
so i can use
CFLAGS="-O2 -pipe -march=native"
at the host (pc1) and inside the chroot (pc2)
becouse the compiler options are only the way how the code will create?
the code at the end is the same
?
CPU_FLAGS_X86
cpuid2cpuflags tells me:
pc1 sandy bridge cpu
Code: | aes avx mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 |
pc2 coffee lake cpu
Code: | aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 |
CPU_FLAGS_X86 are only important for where i do run the programm that is build with the features?
so i can build at pc1 in the chroot the image for pc2 with CPU_FLAGS_X86"aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" even though pc1 cpu does not know "avx2 f16c fma3"
? |
|
Back to top |
|
|
aion1223 n00b
Joined: 05 Oct 2018 Posts: 11
|
Posted: Mon Jan 18, 2021 12:24 am Post subject: |
|
|
Quote: |
so i can use
CFLAGS="-O2 -pipe -march=native"
at the host (pc1) and inside the chroot (pc2)
becouse the compiler options are only the way how the code will create?
the code at the end is the same
?
|
I believe "no" is the answer. Gcc will expand "native" depending on the build host, not the target. In your case, as you are building on pc1 for pc2, pc1 is the build host and pc2 is the target. "Native" will expand for the host, pc1. Even though you did chroot, this is only about files. In the chroot'ed environment, I believe gcc will still refer, say, /proc/cpuinfo which tells the cpu info of pc1.
Quote: |
CPU_FLAGS_X86 are only important for where i do run the programm that is build with the features?
so i can build at pc1 in the chroot the image for pc2 with CPU_FLAGS_X86"aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" even though pc1 cpu does not know "avx2 f16c fma3"
?
|
The answer is no, too. While building the image file, you may be using the programs newly built under the chroot'ed environment. For example, if ever gcc is built & installed under the chroot'ed environment, while you are making the image file, that gcc will be used afterwards. That gcc will run on pc1's processor.
As Hu said, the CPU_FLAGS_X86 as well as the compile options should be compatible for both: pc1 and pc2. If your pc2 is fancier machine -- which seems so --, I guess that it'd be better that installing minimal packages on pc1 with both-compatible compile options & CPU_FLAGS_X86-- just like stage3 --, and continue to build systems on pc2. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54300 Location: 56N 3W
|
Posted: Mon Jan 18, 2021 1:42 pm Post subject: |
|
|
SarahS93,
The chroot needs to be configured gor the target but ...
Code that will run in both places needs to be built with some common -march and CPU_FLAGS.
The simple answer is to build everything that way as its safe.
Note the Code that will run in both places ...
e.g. many things will never be run in the chroot, like KDE, GNOME ... so they can be configured just for the target CPU.
Its not quite that simple either. Some packages build systems build code during the course of the build, then try to execute it on the build host.
That can fail if gcc uses an instruction that he build host does not have.
Then it comes down to how much effort you want to put into configuring your chroot. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6102 Location: Dallas area
|
Posted: Mon Jan 18, 2021 1:54 pm Post subject: |
|
|
Set march for sandybridge, and mtune for skylake.
Sandybridge aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3
Skylake aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
|