| View previous topic :: View next topic |
| Author |
Message |
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2273
Location: $TERM
|
 Posted: Wed Sep 04, 2024 10:59 am Post subject: [crossdev]Migration/maintnance of an existing Gentoo install |
 |
|
Hello everyone!
I'm planning to copy up a gentoo install from an old but more powerful machine to a machine with a newer architecture but it's less powerful (typical e.g. of an old server vs a lower end but newer architecture laptop). Both machines are x86_64, however if I chroot into the laptop's gentoo install, it results in segfaults here and there because of incompatible instruction (and -march=native which I intend to keep).
| Code: | | [17534.512965] python[2202365]: segfault at 10 ip 00007ff4529fcae2 sp 00007ffe29b51ee0 error 4 in libpython3.12.so.1.0[7ff452889000+4be000] likely on CPU 6 (core 3, socket 0) |
I've migrated my Gentoo installs several times before, but this time I intend to MAINTAIN it on the server and do no compiling work on the laptop. The answer is crossdev.
I plan to copy up an existing gentoo install into /usr/x86_64-laptop-linux-gnu/, however crossdev installs packages which has /usr/x86_64-laptop-linux-gnu/bin,lib, and the existing gentoo install also has these directories which results in conflicts. Can someone please suggest what to do? Will it be right to overwrite symlinks /lib and /bin to that of crossdev's directories? No packages install any files in /bin/ but I found files in /lib which belongs to sys-apps/baselayout, sys-apps/hwdata, sys-apps/systemd etc...
ROOT= emerge...
| Code: | | ROOT=/mnt/laptop emerge.... |
Will not work because the build process tends to copy parts of the static libraries form the host machine which which is -march=native therefore older architecture. There are other problems too because (like emerge: there are no ebuilds built with USE flags to satisfy ">=x11-libs/libdrm-2.4.119[video_cards_radeon]".) because of which I'm forced to think about crossroot.
Setting SYSROOT= will not work since it needs more environment variables to work.
_________________
My blog |
|
| Back to top |
|
 |
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2273
Location: $TERM
|
| Posted: Mon Sep 09, 2024 5:27 pm Post subject: |
|
|
Question is: if I copy an existing Gentoo installation to /usr/x86_64-X-linux-gnu, do I really need to install the crossdev toolchain (like x86_64-X-linux-gnu/gcc, x86_64-X-linux-gnu/libc etc...)? Or will it work with just crossdev --init-target (because it seems to be working)?
_________________
My blog |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2273
Location: $TERM
|
| Posted: Wed Sep 11, 2024 6:00 am Post subject: |
|
|
I've realized that the TARGET's glibc conflicts with cross-glibc. I don't know how things are supposed to work with that.
_________________
My blog |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1266
Location: Richmond Hill, Canada
|
| Posted: Sat Nov 23, 2024 4:34 pm Post subject: |
|
|
| dE_logics wrote: | ROOT= emerge...
| Code: | | ROOT=/mnt/laptop emerge.... |
Will not work because the build process tends to copy parts of the static libraries form the host machine which which is -march=native therefore older architecture. There are other problems too because (like emerge: there are no ebuilds built with USE flags to satisfy ">=x11-libs/libdrm-2.4.119[video_cards_radeon]".) because of which I'm forced to think about crossroot.
Setting SYSROOT= will not work since it needs more environment variables to work. |
Do you know that highlighted statement in quote as fact or just speculating? Because I have not seen this behaviour before.
In your first post you said | Quote: | | I plan to copy up an existing gentoo install into /usr/x86_64-laptop-linux-gnu/, however crossdev installs packages which has /usr/x86_64-laptop-linux-gnu/bin,lib, and the existing gentoo install also has these directories which results in conflicts |
I am bit of confuse here because usually stage3 tarball does not create a "/usr/x86_64-laptop-linux-gnu/" so how does this directory come about?
Finally for your objective, I would suggest you use container (docker for example) on the powerful server for building, This will reduce the complexity of setting up cross compiler tool chain. |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2273
Location: $TERM
|
| Posted: Sat Nov 23, 2024 5:21 pm Post subject: |
|
|
| pingtoo wrote: | | Do you know that highlighted statement in quote as fact or just speculating? Because I have not seen this behaviour before. |
Yes, I've seen it in 2018. And even developers warned me recently! See https://bugs.gentoo.org/939450#c7
| pingtoo wrote: | In your first post you said | Quote: | | I plan to copy up an existing gentoo install into /usr/x86_64-laptop-linux-gnu/, however crossdev installs packages which has /usr/x86_64-laptop-linux-gnu/bin,lib, and the existing gentoo install also has these directories which results in conflicts |
I am bit of confuse here because usually stage3 tarball does not create a "/usr/x86_64-laptop-linux-gnu/" so how does this directory come about?
Finally for your objective, I would suggest you use container (docker for example) on the powerful server for building, This will reduce the complexity of setting up cross compiler tool chain. |
Container is like a chroot (but namespaced). So if I use -march=<some other machine>, it will fail in many cases because it does not translate instructions.
_________________
My blog |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1266
Location: Richmond Hill, Canada
|
| Posted: Sat Nov 23, 2024 5:33 pm Post subject: |
|
|
| dE_logics wrote: | | pingtoo wrote: | | Do you know that highlighted statement in quote as fact or just speculating? Because I have not seen this behaviour before. |
Yes, I've seen it in 2018. And even developers warned me recently! See https://bugs.gentoo.org/939450#c7 |
I see. So it is mostly relate to build time dependency
| Quote: | | pingtoo wrote: | In your first post you said | Quote: | | I plan to copy up an existing gentoo install into /usr/x86_64-laptop-linux-gnu/, however crossdev installs packages which has /usr/x86_64-laptop-linux-gnu/bin,lib, and the existing gentoo install also has these directories which results in conflicts |
I am bit of confuse here because usually stage3 tarball does not create a "/usr/x86_64-laptop-linux-gnu/" so how does this directory come about?
Finally for your objective, I would suggest you use container (docker for example) on the powerful server for building, This will reduce the complexity of setting up cross compiler tool chain. |
Container is like a chroot (but namespaced). So if I use -march=<some other machine>, it will fail in many cases because it does not translate instructions. |
Yes I also call container as glorified chroot.
If you do the build inside chroot(or container) you should not need cross compile and still using same CPU power as host. So why cross compile still need? is it because you prefer not doing the chroot setup? (as in mounting those pseudo file systems and unmount afterword) |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2273
Location: $TERM
|
| Posted: Sat Nov 23, 2024 5:53 pm Post subject: |
|
|
Doing a chroot for another machine X on the host Y (with a different CPU) will result in machine X's binaries (which is built using -march=native on machine X) run on Y. Unfortunately the binaries of X and Y are not completely compatible -- binaries of X contain instructions which Y does not understand.
As a result --
| Code: | traps: TaskCon~ller #5[195099] trap invalid opcode ip:7f6128f38686 sp:7f611a6c27d0 error:0 in libxul.so[3737686,7f6127ff6000+8723000]
python[2202365]: segfault at 10 ip 00007ff4529fcae2 sp 00007ffe29b51ee0 error 4 in libpython3.12.so.1.0[7ff452889000+4be000] likely on CPU 6 (core 3, socket 0)
traps: protoc[2762543] trap invalid opcode ip:564ee6216980 sp:7ffc2a8311b0 error:0 in protoc |
Yup. I got too many of these because of chrooting.
_________________
My blog |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1266
Location: Richmond Hill, Canada
|
| Posted: Sat Nov 23, 2024 6:20 pm Post subject: |
|
|
| dE_logics wrote: | Doing a chroot for another machine X on the host Y (with a different CPU) will result in machine X's binaries (which is built using -march=native on machine X) run on Y. Unfortunately the binaries of X and Y are not completely compatible -- binaries of X contain instructions which Y does not understand.
As a result --
| Code: | traps: TaskCon~ller #5[195099] trap invalid opcode ip:7f6128f38686 sp:7f611a6c27d0 error:0 in libxul.so[3737686,7f6127ff6000+8723000]
python[2202365]: segfault at 10 ip 00007ff4529fcae2 sp 00007ffe29b51ee0 error 4 in libpython3.12.so.1.0[7ff452889000+4be000] likely on CPU 6 (core 3, socket 0)
traps: protoc[2762543] trap invalid opcode ip:564ee6216980 sp:7ffc2a8311b0 error:0 in protoc |
Yup. I got too many of these because of chrooting. |
But why are you doing -march=native in chroot? that would defeat the idea. You should set your CFLAGS for your -march=<target CPU>
For crossdev setup if you still using -march=native in the /usr/<target>/etc/portage/make.conf you will get same result (none functional binary). GCC can be instructed create any kind of binary as long as it is given right flags. so having crossdev in your idea may or may not do what you want. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54584
Location: 56N 3W
|
| Posted: Sat Nov 23, 2024 6:55 pm Post subject: |
|
|
segfaults are not incompatible instruction sets
They mean that something tried to access memory it does not own.
Incompabible instruction sets give Illegal Instruction exceptions.
Crossdev is not useful as both systems are amd64.
It should not be possible to install an amd64 target cross toolchain on an amd64 host. That would be a crossdev bug.
A chroot/namespace is the way to go.
You need to discover what -march=native means on the target then use that explicity on the build box.
There is a wiki page about building in a 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 |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2452
|
| Posted: Sat Nov 23, 2024 7:14 pm Post subject: |
|
|
You can safely use the binaries built for the older CPU on the newer. If they are both X86_64 you won't notice a difference.
If they are both X86_64-v2 compatible, the different would be even more marginal.
Best Regards,
Georgi |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2273
Location: $TERM
|
| Posted: Sun Nov 24, 2024 4:58 am Post subject: |
|
|
By -march=native I imply -march=native on a machine FROM which the ROOT is copied over. In reality I use -march=<machine type>.
I'm not getting segfaults, I'm getting 'invalid opcode' even during compiling. For e.g. chrome, firefox will always fail with -march=<machine type>. QT will never works it results in error 'incompatible processor' and lists instructions which are not available on the build host.
Also the build host is an older system and is an AMD while the target is an intel and newer gen.
_________________
My blog
Last edited by dE_logics on Sun Nov 24, 2024 5:15 am; edited 1 time in total |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2273
Location: $TERM
|
| Posted: Sun Nov 24, 2024 5:13 am Post subject: |
|
|
Speaking of incompatible instruction I though x86 allowed optional extension instructions -- if on an older processor execute older instructions while on a newer one execute these instructions.
But it turned out to be a gimmick.
| gcc man page wrote: | | -march=cpu-type allows GCC to generate code that may not run at all on processors other than the one indicated. |
_________________
My blog |
|
| Back to top |
|
|
|
Portage & Programming
