Hi,
I am receiving the following error when I try to compile procps-ng in
section 6.27 and would appreciate some help:
---- snip
make[2]: Entering directory '/sources/7.8-rc1/procps-ng-3.3.11'
CC free.o
free.c: In function 'scale_size':
free.c:137:5: internal compiler error: Illegal instruction
snprintf(buf, sizeof(buf), "%ld", (long int)(size / 0.9765625));
^
0x963e6f crash_signal
../../gcc-5.2.0/gcc/toplev.c:383
0x7f313dc4764f ???
/sources/7.8-rc1/glibc-2.22/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
----snip
Originally, this was going to be a different question, but through the
process of troubleshooting, it has become clear to me that this has
something to do with the VM and not procps-ng-3.3.11. My setup may be a
little different than the norm, but I am hoping y'all will bear with me.
Here are my two setups:
1. MacBook Pro Quad-Core i7 2.6 GHz, 1TB Hybrid SSD, 16GB RAM
Virtualbox 4.3.28 with the extension pack
Vagrant 1.7.4 to manage virtual boxes
archlinux-2015.09.01 as the LFS environment host (1 CPU, 2048 or 4096
RAM - tried both)
LFS 7.8-rc1
2. Dell Optiplex 755 Quad-Core Core2 2.8 GHz, 256GB SSD, 8GB RAM
Virtualbox 4.3.30 with the extension pack
Vagrant 1.6.5 to manage virtual boxes
archlinux-2015.09.01 as the LFS environment host (1 CPU, 2048 or 4096
RAM - tried both)
LFS 7.8-rc1
The dell-arch instance is a clone of the mac-arch instance as of LFS
6.20 - Ncurses-6.0. (I packaged the running VM at that point and copied
it over to the dell to run in its virtualbox environment)
I wrote a dummy function to test this issue and ran it in several
scenarios. Here is the dummy code:
cat > dummy.c << "EOF"
#include <stdio.h>
main()
{
long int x;
x = (long int) 5 / 0.9765625;
printf("%ld\n", x);
}
EOF
g++ -o dummy dummy.c
./dummy
This code executes on the mac, the dell, inside both archlinux virtual
evironments, and in the hosted LFS environment on the mac-arch instance.
It fails with an illegal instruction error on the dell-arch instance in
the LFS environment. If I look at proc/cpuinfo inside the mac-arch
hosted LFS chroot, I get this result:
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
stepping : 9
microcode : 0x19
cpu MHz : 2604.297
cache size : 6144 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm
constant_tsc rep_good nopl pni monitor ssse3 lahf_lm
bugs :
bogomips : 5208.59
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Looks like a slice of my macbook.
When I do it inside the dell-arch hosted LFS chroot, I get this result:
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz
stepping : 7
microcode : 0x70b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1
lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips : 5652.47
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Which looks like a slice of my dell.
My questions to y'all are - does anyone have any experience moving a
virtual machine with LFS on it from one host platform to another and
have you experienced similar issues? Do you have any suggestions of how
to address the issue?
FYI, I snapshot the VMs before and after any major part of the book, so
I am able to walk backward from the current snapshot to various
milestones such as building glibc, gcc, the initial toolchain, etc.
Thanks,
Will
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
