I investigated as to why my grub wouldn't install when it looked like the compile was OK. Now emerging GDB and also attempting to re-emerge with different CFLAGS (just -O2, removing -march=native).
Taro build-pc # ./grub-mkimage --help Usage: grub-mkimage [OPTION...] [OPTION]... [MODULES] Make a bootable image of GRUB. -c, --config=FILE embed FILE as an early config Segmentation fault (core dumped)
What's weird is it should just be printing some output. That shouldn't crash it unless there is a major bug.
Well ... it installed. Is there some way to tell portage to change CFLAGS for a certain program? Is there an /etc/portage/package.cflags? I know the ebuilds can do it, but the ebuild isn't filtering out -march=native, which is definately breaking grub (like a bug somewhere). I'm gonna compile the broken one, just so I can gdb it.
Program received signal SIGSEGV, Segmentation fault. 0x000000000041459a in memset () (gdb) bt #0 0x000000000041459a in memset () #1 0x0000000000414672 in memset () #2 0x0000000000414672 in memset () #3 0x0000000000414672 in memset () #4 0x0000000000414672 in memset ()
This repeats until the stack overflows ... at least 10000 times. Weird eh?
I think its related to this GCC bug: https://gcc.gnu.org/...ug.cgi?id=56888
It looks like even gcc's own test suite caches the bug and yet they released it anyway :/ Only bites with -O3 when doing something like that looks like a memcopy. GCC will optimize by calling the library routine which can result in an infinite loop. In which case you can fix the source with:
#pragma GCC optimize ("no-tree-loop-distribute-patterns")
Or just tweak the ebuild to add "-fno-tree-loop-distribute-patterns" to the CFLAGS in the ebuild and be done with it.
Yup - this fixes it! Off to file a bug. (and keeping that -fno-tree-loop-... in my global CFLAGS, who knows what other apps will silently fail - I should probably recompile EVERYTHING).