Description of problem: This description will be long, sorry for the redundant information. I compiled few C application using the system default compiler (gcc 4.3.2 on fedora 10), and then I tried to run them on some older systems, and the result is always a Floating point exception: torre@bart:~/tmp/float_bug_report$ ./hello_world Floating point exception This is the simple hello world: torre@lou:~/tmp/float_bug_report$ cat hello_world.c #include <stdio.h> int main(int argc, char ** argv) { printf("Hello World!\n"); return 0; } Details of the system I am running gcc: torre@lou:~/tmp/float_bug_report$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz stepping : 13 cpu MHz : 1203.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4373.15 clflush size : 64 power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz stepping : 13 cpu MHz : 1203.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4387.02 clflush size : 64 power management: torre@lou:~/tmp/float_bug_report$ uname -a Linux lou 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux torre@lou:~/tmp/float_bug_report$ gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Thread model: posix gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) -------- Details on the system I try to run the executable: torre@bart:~/tmp/float_bug_report$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) XP 2200+ stepping : 1 cpu MHz : 1813.636 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts bogomips : 3629.71 torre@bart:~/tmp/float_bug_report$ uname -a Linux bart 2.6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 i686 athlon i386 GNU/Linux torre@bart:~/tmp/float_bug_report$ gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.0 (SUSE Linux) ------- As you see, this is an old AMD Athlon(tm) XP 2200+. I experienced this on Pentium IV machines too, but not on other systems. This is an example: torre@lenny:~/tmp/float_bug_report$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 79 model name : AMD Sempron(tm) Processor 3200+ stepping : 2 cpu MHz : 1890.043 cache size : 128 KB fpu : yes fpu_exception : yes cpuid level : 1 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 mmxext fxsr_opt rdtscp lm 3dnowext 3dnow up pni cx16 lahf_lm cr8_legacy bogomips : 3784.04 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc torre@lenny:~/tmp/float_bug_report$ uname -a Linux lenny 2.6.18.8-0.11-default #1 SMP Sat Oct 11 16:17:11 UTC 2008 x86_64 x86_64 x86_64 GNU/Linux torre@lenny:~/tmp/float_bug_report$ gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux Thread model: posix gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) On this last system, the application runs fine. All test are run disabling the floating point extensions: gcc -march=i386 -m32 hello_world.c -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-ssse3 -mno-3dnow -o hello_world -g -O0 --verbose Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Thread model: posix gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-mno-mmx' '-mno-sse' '-mno-sse2' '-mno-sse3' '-mno-ssse3' '-mno-3dnow' '-o' 'hello_world' '-g' '-O0' '-v' /usr/libexec/gcc/i386-redhat-linux/4.3.2/cc1 -quiet -v hello_world.c -quiet -dumpbase hello_world.c -march=i386 -m32 -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-ssse3 -mno-3dnow -auxbase hello_world -g -O0 -version -o /tmp/ccUfc7Oa.s ignoring nonexistent directory "/usr/lib/gcc/i386-redhat-linux/4.3.2/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../i386-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/i386-redhat-linux/4.3.2/include /usr/include End of search list. GNU C (GCC) version 4.3.2 20081105 (Red Hat 4.3.2-7) (i386-redhat-linux) compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3bee52601079f736b7b63b762646f4ba COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-mno-mmx' '-mno-sse' '-mno-sse2' '-mno-sse3' '-mno-ssse3' '-mno-3dnow' '-o' 'hello_world' '-g' '-O0' '-v' as -V -Qy -o /tmp/ccknE8Yg.o /tmp/ccUfc7Oa.s GNU assembler version 2.18.50.0.9 (i386-redhat-linux) using BFD version version 2.18.50.0.9-7.fc10 20080822 COMPILER_PATH=/usr/libexec/gcc/i386-redhat-linux/4.3.2/:/usr/libexec/gcc/i386-redhat-linux/4.3.2/:/usr/libexec/gcc/i386-redhat-linux/:/usr/lib/gcc/i386-redhat-linux/4.3.2/:/usr/lib/gcc/i386-redhat-linux/:/usr/libexec/gcc/i386-redhat-linux/4.3.2/:/usr/libexec/gcc/i386-redhat-linux/:/usr/lib/gcc/i386-redhat-linux/4.3.2/:/usr/lib/gcc/i386-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/i386-redhat-linux/4.3.2/:/usr/lib/gcc/i386-redhat-linux/4.3.2/:/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-mno-mmx' '-mno-sse' '-mno-sse2' '-mno-sse3' '-mno-ssse3' '-mno-3dnow' '-o' 'hello_world' '-g' '-O0' '-v' /usr/libexec/gcc/i386-redhat-linux/4.3.2/collect2 --eh-frame-hdr --build-id -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -o hello_world /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../crt1.o /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../crti.o /usr/lib/gcc/i386-redhat-linux/4.3.2/crtbegin.o -L/usr/lib/gcc/i386-redhat-linux/4.3.2 -L/usr/lib/gcc/i386-redhat-linux/4.3.2 -L/usr/lib/gcc/i386-redhat-linux/4.3.2/../../.. /tmp/ccknE8Yg.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i386-redhat-linux/4.3.2/crtend.o /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../crtn.o torre@bart:~/tmp/float_bug_report$ gdb hello_world GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/torre/tmp/float_bug_report/hello_world Program received signal SIGFPE, Arithmetic exception. 0xb7fce1fb in do_lookup_x () from /lib/ld-linux.so.2 I tried using older fedora, with gcc4.1, but the result was the same. Running gcc4.1 on the suse machine produces an executable that I can run on all the tested platforms. These are the flags for the suse gcc: torre@lenny:~/tmp/float_bug_report$ gcc -o hello_world hello_world.c -m32 --verbose Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux Thread model: posix gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) /usr/lib64/gcc/x86_64-suse-linux/4.1.2/cc1 -quiet -v hello_world.c -quiet -dumpbase hello_world.c -m32 -mtune=generic -auxbase hello_world -version -o /tmp/cc92aCn0.s #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/4.1.2/include /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/include /usr/include End of search list. GNU C version 4.1.2 20061115 (prerelease) (SUSE Linux) (x86_64-suse-linux) compiled by GNU C version 4.1.2 20061115 (prerelease) (SUSE Linux). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 8b4fcf258036cbfdd15421c708a78d09 /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/as -V -Qy --32 -o /tmp/ccUAKDAS.o /tmp/cc92aCn0.s GNU assembler version 2.17.50.0.5 (x86_64-suse-linux) using BFD version 2.17.50.0.5 20060927 (SUSE Linux) /usr/lib64/gcc/x86_64-suse-linux/4.1.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello_world /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib/crt1.o /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib/crti.o /usr/lib64/gcc/x86_64-suse-linux/4.1.2/32/crtbegin.o -L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/32 -L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/lib/../lib -L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib64/gcc/x86_64-suse-linux/4.1.2 -L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../.. /tmp/ccUAKDAS.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib64/gcc/x86_64-suse-linux/4.1.2/32/crtend.o /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib/crtn.o Version-Release number of selected component (if applicable): torre@lou:~/tmp/float_bug_report$ rpm -q gcc gcc-4.3.2-7.i386 But older compilers behave the same How reproducible: Compile the application and run on different systems Steps to Reproduce: 1. Compile the app 2. Run on an older system Actual results: Floating point exception Expected results: Hello World! Additional info: Tested with fedora 10, i386 and fedora 8 x86_64
That's user error. You generally cannot expect to compile stuff on a new distro and run the binary on much older one, symbols are being added to glibc and many other stuff. This particular crash is because very old glibcs didn't support DT_GNU_HASH. You can link with -Wl,--hash-style=sysv to avoid this, but generally you can't avoid added symbols.
Hi Jakub, thanks for the quick reply. I was sure it was something like this, but the reason why I submitted the bug report is because it works with SuSe machines. As noted, -Wl,--hash-style=sysv does the job. Thanks, Mario
This is a bug. This is not user error. gcc (through 4.4.1) is doing the wrong thing by passing --hash-style=gnu to the linker. According to readelf or (ldd -v) the executables currently produced by gcc depend on GLIBC_2.2.5. So if I take one of those to a system where /lib64/ld-linux-x86-64.so.2 is ld-2.3.4.so then I expect it to run. I hope you agree that this is a reasonable expectation. Please make the default hash-style either "sysv" (as man ld says it is) or "both." Is there a problem with "both?" If not then you could save a lot of headaches, as getting killed by SIGFPE is sort of obscure as an indication of glibc mismatch.
I too believe this to be a bug. Using gcc 4.1.2 followed by "objdump -p" there is nothing to suggest the executable requires symbols in glibc > 2.0 but in fact the program will not run on a system with glibc 2.3.4 unless the "-Wl,--hash-style=sysv" workaround is used. The error message is not a great help either. If the executable requires a later glibc then that should be recorded in the objdump -p output. [root@rothvoel036 dl]# uname -a Linux rothvoel036 2.6.18-128.el5 #1 SMP Wed Jan 21 07:58:05 EST 2009 i686 i686 i386 GNU/Linux [root@rothvoel036 dl]# cat a.c #include "stdio.h" int main() { printf("Hello world\n"); } [root@rothvoel036 dl]# gcc412 a.c [root@rothvoel036 dl]# objdump -p a.out | tail RELSZ 0x8 RELENT 0x8 VERNEED 0x804820c VERNEEDNUM 0x1 VERSYM 0x8048202 Version References: required from libc.so.6: 0x0d696910 0x00 02 GLIBC_2.0 [root@rothvoel036 dl]# ./a.out Hello world [root@rothvoel036 dl]# ssh lovedada@wobble Last login: Sun Apr 15 22:09:37 2012 from 10.228.199.36 [lovedada@wobble ~]$ ./a.out Floating point exception [lovedada@wobble ~]$ ls -l /lib/libc.so.6 lrwxrwxrwx 1 root root 13 Feb 12 2009 /lib/libc.so.6 -> libc-2.3.4.so [lovedada@wobble ~]$