Here is the end of my output from trying to build sys-devel/m4-1.4.10: i686-pc-linux-gnu-gcc -std=gnu99 -march=athlon-tbird -mmmx -m3dnow -O2 -fomit-frame-pointer -floop-optimize -funroll-loops -fbranch-target-load-optimize -funswitch-loops -maccumulate-outgoing-args -minline-all-stringops -ffast-math -pipe -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,-z,combreloc -o m4 m4.o builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o path.o symtab.o stackovf.o ../lib/libm4.a ../lib/libm4.a(vasnprintf.o): In function `vasnprintf': vasnprintf.c:(.text+0x2469): undefined reference to `decimal_point_char' vasnprintf.c:(.text+0x2524): undefined reference to `decimal_point_char' vasnprintf.c:(.text+0x25e2): undefined reference to `decimal_point_char' vasnprintf.c:(.text+0x2697): undefined reference to `decimal_point_char' collect2: ld returned 1 exit status make[1]: *** [m4] Error 1 make[1]: Leaving directory `/var/tmp/portage/sys-devel/m4-1.4.10/work/m4-1.4.10/src' make: *** [all-recursive] Error 1 According to GNU, 1.4.10 is the latest stable version, as seen here: http://www.gnu.org/software/m4/ However, my problem seems to be a known bug, as seen here: http://www.nabble.com/Re:-m4-1.4.10-compile-error:-unsigned-reference-to-decimal_point_char-t4076963.html Applying the patch seen at this page does allow me to compile m4, but I haven't tested it because I don't use it explicitly, myself.
Created attachment 131654 [details, diff] The patch to m4-1.4.10 to make it build. This is the patch to m4-1.4.10 as found here: http://www.nabble.com/Re:-m4-1.4.10-compile-error:-unsigned-reference-to-decimal_point_char-t4076963.html
*** This bug has been marked as a duplicate of bug 185998 ***
Bug #185998 has been marked invalid and closed, which appears to be incorrect. This may explain why I didn't find bug #185998 when I searched for 'm4', before I filed this bug. This does appear to be an actual bug, regardless of whether it is triggered by -ffast-math or not. Please could whoever closed #185998 as invalid be more careful.
The main thing that is buggy here is your global C[XX]FLAGS. Sticking -ffast-math there is plain stupid, sorry.
Quoting comment #4: "Sticking -ffast-math there is plain stupid, sorry." - You seem to have a terrible manner Jakub Moc. I would disagree that it is 'stupid' to use -ffast-math, because it seems to rarely *actually* break things (despite the deviant behaviour), and even though it does break compilation of this package, it is apparently only by triggering an actual bug. I am sensible enough to test without compiler flags, if I can not find bug reports. I would advise ordinary 'users' not to activate -ffast-math themselves. Jakub Moc, if you bad manner results from a sense that I shouldn't even be reporting this bug, I ask you to reexamine the details of this bug. Anyway, I've been delving further in to the bug and when I diffed the compilation output from CFLAGS="" and CFLAGS="-ffast-math" (in this order), I found this: -checking whether printf supports infinite 'double' arguments... yes +checking whether printf supports infinite 'double' arguments... no It appears to be acceptable/normal to not support "infinite 'double' arguments", which is why configure tests for this at all. I looked in the configure file, and found the test involves some esoteric 'floating point logic' (things like 'NaNs'), and so it shouldn't be surprising that this is broken by -ffast-math (deliberately of course). The m4 bug is triggered later because of an oversight apparently. I only include this in case it becomes useful for later bugs.
There's nothing to re-examine here, your m4 issue will be fixed when upstream releases a new version, as said on the other bug. That doesn't change zilch about the fact that -ffast-math is a stupid global flag, as man gcc suggests. <snip> This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. </snip>
