Re: copy lfs build to older CPU

Hallo,
> dmesg should show exactly which file contains the offending instruction.
> Like:
>
> [10066.276138] traps: a.out[100368] trap invalid opcode ip:7f0720a5f100 sp:7ffdcdaafd58 error:0 in t.so[1100,7f0720a5f000+1000]
>
> And which exact files have you replaced?

I followed the instructions on the libffi and gmp packages, then used 
"make DESTDIR=" to catch the files, transferred exactly the freshly 
compiled files to the target and rebooted to make sure the new files are 
there and not some cached old.

Still got the error below. dmesg showed nothing. Compiling the first few 
files went through, and it choked here:

make[1]: Entering directory '/sources/ethtool-5.0'
   CC       sff-common.o
sff-common.c: In function "convert_mw_to_dbm":
sff-common.c:29:9: internal compiler error: Illegal instruction
    29 |         return (10. * log10(mw / 1000.)) + 30.;
       |         ^~~~~~


I admit, I gave up at that point after recompiling libffi and gmp 3 times.
I read through the book again to find more places with CPU-related hints 
but found nothing more related to gcc and compiling packages.

I then created a VM on a Fedora system, defined the CPU as "core2duo" 
(which gets translated to "qemu64") and *that* LFS build now runs on the 
i5-3350 - I could compile all the rest of the packages I'd like to have 
on my systems. I'll continue from there. I always have 2 partitions on 
each machine I build, to have LFS build itself again with the latest gcc 
(a bit similar to Android's A/B concept).

Downgrading a CPU for a VM works ok, the speed is still good, KVM simply 
defines less CPU capability bits to the virtual machine.

Thanks for the suggestions and the help. I learn something new every day :-)

Stay healthy,
Thomas
-- 
"Do you wanna be a legend or a passing footprint on the sands of time?"

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page