[crossdev]Migration/maintnance of an existing Gentoo install

[dE_logics]

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).

[dE_logics]

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

[dE_logics]

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

[pingtoo]

[dE_logics]

[pingtoo]

[dE_logics]

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 --

[pingtoo]

[NeddySeagoon]

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.

[logrusx]

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

[dE_logics]

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

[dE_logics]

Speaking of incompatible instruction I though x86 allowed optional extension instructions -- if on an older processor it executes an older instructions while on a newer one it executes the newer instructions.

But it turned out to be a gimmick.

[pingtoo]

[NeddySeagoon]

AMD and Intel have always had incompatiple instruction set extensions.
Intel started with MMX, AMD added 3dnow!

It's been downhill from there.

See the building in a chroot wiki page for how to handle it.
I would post a link but I'm on my phone.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[dE_logics]

[dE_logics]

[pingtoo]

dE_logics,

I wish I can be more of help. but I can't because I don't know how to parse your current post and the bug report 944725.

And the reason is in chroot there is usually no need to have ROOT=<something> whereas in that bug report you state "ROOT=" I don't know that mean ROOT have a value of something you just want to hide or ROOT have value of blank or no environment variable ROOT at all.

I assume the emerge --info output include in your last post is executed inside chroot environment, It looks fine to me. One suggestion is you might want to enable build binary in EMERGE_DEFAULT_OPTS and possible use --with-bdeps=y instread =n because you want this to be your build environment.

your USE flag have "pgo", this will NOT work in this different CPU setup (Intel vs AMD). Because you target build is Intel machine but executed on AMD, the pgo will run binary for Intel which most likely will fail.

your bug report 955725 is failed for the above "pgo" reason.

For me, in order to understand and make suggestion, I usually need to be sure the environment that got error condition need very obviously (as in verbose), I usually need exactly the command that cause the error and some indication the environment condition. In this case you post the output as I asked, however I don't know if this is inside chroot or not or this is crossdev-emerge output . If you had include the host emerge --info in the same post then I will be able to know for sure. Please note I am not blaming. I just try to explain my way of debugging and a example how I would know for sure. the other possible would be you post include the command prompt which have indicator it is in chroot.

[dE_logics]

The bug report is for a cross compile (ROOT=). I did not report a bug with chroot because it would've been invalid since -march=<cpu> was for a different host and the toolchain was not cross compiling. Regardless, it results the same error in chroot.

ROOT point to the target's root directory -- it varies.

Your PGO point might be right -- but that's exactly the reason why I'm cross compiling instead of chrooting. If not firefox, then chromium, if not chromium then QT and KDE always fail.

The emerge --info was in chroot.

Overall, even the devs agree that in this situation (AMD/intel, building on older machines for newer ones etc...) you need to cross compile -- it is the only proper solution. Unfortunately it seems crossdev is unmaintained, the new devs don't have much idea about it and they seem to be unsure on what should be done in these situations.
_________________
My blog

[pingtoo]

[logrusx]

AFAIK PGO is hardware dependent and it doesn't make much sense to do it on another computer. Also, as pingtoo says, part of the optimization is to gather profile data by running it. You can't run the newer binary on the older processor. There's another way of doing it, building a special version of the software you want to optimize, let it run for a couple of weeks and it'll gather the data, then supply that data to emerge which'll then produce an optimized binary. However I haven't done it and I can't give an advice or even point you to a relevant resource on the topic.

I'll say it again, build for a generic x86_64 or find the common denominator for both computers.

Best Regards,
Georgi

[dE_logics]

Ok. Thanks for clarifying that. I will rebuild without PGO and see after I try changing my CHOST (since it's invalid configuration otherwise).
_________________
My blog

[dE_logics]

Even bash was failing because of that. Thanks for the pointer.
_________________
My blog