sys-devel/m4-1.4.11 fails to build, while linking together the actual m4 executable. This seems to be because libm4.a contains two bad object files: lib/clean-temp.o and lib/gl_linkedhash_list.o contain ASCII text instead of object code. clean-temp.o even seems to contain XML related C code, something I didn't really think one would find anywhere in the M4 source code :) I've tried remerging without the nls USE flag, but get the same result. I could not spot any glaring errors in the Makefile.am, but then again I am no automake expert. I just don't know what it could be at this point. Reproducible: Always Steps to Reproduce: 1. emerge m4
Created attachment 152009 [details] The build log
Created attachment 152011 [details] The environment.
Created attachment 152013 [details] lib/clean-temp.o, an ASCII file.
Created attachment 152015 [details] lib/gl_linkedhash_list.o, another ASCII file.
every time we've seen this sort of error in the past, it was due to messed up filesystem. please reboot and force a fsck on the disks in question.
(In reply to comment #5) > every time we've seen this sort of error in the past, it was due to messed up > filesystem. please reboot and force a fsck on the disks in question. I haven't rebooted quite yet, but what I did do was mount a temporary partition from a different disk (LVM LE, specifically created for this test) on /var/tmp/portage. This test partition is formatted with ext3 (the original /var/tmp/portage is reiserfs). The exact same error still occurs even though the files are put on this new, external partition. Since this test didn't result in a successful build, I will now proceed to rebooting and checking the original partition like you said (and report results here).
(In reply to comment #5) > every time we've seen this sort of error in the past, it was due to messed up > filesystem. please reboot and force a fsck on the disks in question. > Rebooted to a Gentoo 2007.0 minimal CD and did the check (plain reiserfsck <dev>). No corruptions found. I am sure I checked the right partition (i.e. that the boot CD didn't detect various /dev/hdX in another order), too, because all others are either 1) another file system type or 2) swap or 3) part of an md device.
Found the error. It was ccache that kept inserting this nonsense into the object files. I guess either the ccache is broken (it's monstrously large, at 871 MB), or the cache hit algorithm isn't completely sane. I had completely forgotten that ccache was enabled on this machine and feel a bit embarassed about reporting this as a M4 bug without recompiling with it off first. I think I'll just leave ccache disabled from now on.
