Il 20/08/24 22:42, Dale ha scritto:

If you are in no hurry for the new system to be available once built,
I'd consider this way.  Leave current system as is.  If you start compiling, it could die while compiling depending on what the problem
is.  I'd assemble the new system, test from some boot media, make sure memory, CPU and all that works.  In other words, not dead out of the
box.  Then install the hard drive OS from the old system.  Boot the boot media, mount and chroot into the old install.  Make the needed changes

As mentioned in another post I tried a similar route in the past (not
chroot but directly boot from the old install) and it did not work. At
the time I assumed the instruction sets were different between the
Athlon and the Ryzen and gave up, reinstalling the new rig from stage 3.
I'm not so convinced that was the problem, but this subject is far too
complex given the time I can invest on it.

in make.conf, don't forget CPU flags if set, and start a emerge -e
world.  One advantage of compiling on newer rig, it is faster than the
old rig.  Another advantage, you only need to do it once.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il 20/08/24 19:38, Eli Schwartz ha scritto:

On 8/20/24 1:23 PM, ralfconn wrote:

my 8-year old gentoo HTPC is giving clear signals that the motherboard
is about to die so I ordered new components.

The dying box is an AMD FX-6530 built with -march=native. The new box
will be Ryzen 7 5800X.

The other safe option is to run `ld.so --help` and check for this:

Subdirectories of glibc-hwcaps directories, in priority order:
    x86-64-v4
    x86-64-v3 (supported, searched)
    x86-64-v2 (supported, searched)

Your new CPU should support -march=x86-64-v3 but perhaps the old one doesn't.

If you plan to recompile all packages with -march=native immediately
after you swap anyway, then it doesn't really matter, just use "x86-64"
for maximum compatibility.

The command on the old rig outputs:

  x86-64-v4
  x86-64-v3
  x86-64-v2 (supported, searched)

while on another box with a Ryzen 9 5900x it output the same as your
example (-v3 and -v2 supported).

I did not know about this 'Microarchitecture level' definition [1],
thanks. I'd expect the -v3 to be a superset of the -v2, instead when in
the past I tried to boot a Ryzen 9 from a system built with
-march=native for an FX 8530 it did not work (I don't remember if it was
a kernel panic or if it stopped already at GRUB, I think the latter), so
I had to reinstall from stage 3.

raffaele

[1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hGajCg1AcGR8NpJFDfm6l07X
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8/21/24 12:34 AM, ralfconn wrote:

I did not know about this 'Microarchitecture level' definition [1],
thanks. I'd expect the -v3 to be a superset of the -v2, instead when in
the past I tried to boot a Ryzen 9 from a system built with
-march=native for an FX 8530 it did not work (I don't remember if it was
a kernel panic or if it stopped already at GRUB, I think the latter), so
I had to reinstall from stage 3.

raffaele

[1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

Yup, that is the great advantage of these microarchitecture "common
levels". Unlike -march=native which just toggles every single tiny
option your current CPU supports, these are strictly defined supersets
designed to work with, basically, "any CPU produced after a certain
date". It makes it much easier to deliver common optimizations to a mere
3 distinct configurations. Also it makes it much easier to rapidly tell
which group your current CPU supports.



Gentoo's official binhost uses these too. Well, the binhost provides a
regular generic -march=x86-64 set of binary packages, plus a set that
targets the -march=x86-64-v3 seriesdsfe. No "v2" or "v4" packages there,
I'm afraid. :)


--
Eli Schwartz


--------------hGajCg1AcGR8NpJFDfm6l07X--

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZsV6YwUDAAAAAAAKCRCEp9ErcA0vV/LL AQDF0uEkT967GjzbLnodn0Dhl8X29+vx7H0lp3BBE12zwQEAiouV4kvLsrgQ3dpr9TnoFPKQiAXL NVNIEzbY1X4oVwY=
=4ond
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)