I haven't investigated yet but both archs fail with the same error (missing key.c), here is the snippet: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../gnulib/lib -I../gnulib/lib -DLOCALEDIR=\"/home/jolexa/portage/linux-32/usr/share/locale\" -DINFODIR=\"/home/jolexa/portage/linux-32/usr/share/info\" -DINFODIR2=\"/home/jolexa/portage/linux-32/usr/share/info\" -O2 -pipe -fomit-frame-pointer -MT key.o -MD -MP -MF .deps/key.Tpo -c -o key.o key.c make[3]: Nothing to be done for `install-data-am'. cc1: error: key.c: No such file or directory ..//info/makedoc ./session.c ./echo-area.c ./infodoc.c ./m-x.c ./indices.c ./nodemenu.c ./footnotes.c ./variables.c make[3]: *** [key.o] Error 1 make[3]: *** Waiting for unfinished jobs.... mv -f .deps/m-x.Tpo .deps/m-x.Po make[3]: Leaving directory `/home/jolexa/portage/linux-32/var/tmp/portage/sys-apps/texinfo-4.11-r1/work/texinfo-4.11/info' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/home/jolexa/portage/linux-32/var/tmp/portage/sys-apps/texinfo-4.11-r1/work/texinfo-4.11/info' make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/jolexa/portage/linux-32/var/tmp/portage/sys-apps/texinfo-4.11-r1/work/texinfo-4.11/info' make: *** [install-recursive] Error 1
This is the same reason why it is masked on Solaris. It did compile for me on amd64 linux... :/ I'll move the mask to global scope again, as it seems unpredictable for who it works and for who it doesn't (linux works for me, fails for you)
hmpf. works on darwin though... ...always has, always will.
@pipping: since you're in charge of Darwin, feel free to unmask there if you're confident enough.
Created attachment 137260 [details, diff] Do not allow parallel install This patch fixes the problem for me, parallel install doesn't seem to work. The log line just before the failing compiler run is "rm -f key.c ..."
I could swear I've tried that... maybe I only did it on the make, not the make install. darksiide, does that work for you?
(In reply to comment #5) > I could swear I've tried that... > > maybe I only did it on the make, not the make install. darksiide, does that > work for you? Yes, confirmed works. Thanks Stefan
cc-ing base-system as I imagine this bug not to be Alt/Prefix specific. I'll apply Stefan's workaround and unmask. Thanks Stefan!
(In reply to comment #5) > I could swear I've tried that... > > maybe I only did it on the make, not the make install. darksiide, does that > work for you? I had added -j1 to make at first, too. Compiler calls during make install can be at times confusing ;-)
no compiling should be done by `make install` and none is done on a linux system figure out why compiling is happened at all rather than adding workarounds that are not the right route
it looks like the problem is related to rm -f doc.c key.c funs.h appearing multiple times during make. consecutive runs of make compile sources over and over again (infodoc.o, infomap.o, m-x.o, doc.o, ginfo, infokey). The Makefile tells these three are generated by ./makedoc, which explains why a rebuild is triggered every time, given the rm. Problem seems to be that doc.c key.c funs.h are always rebuilt (rm -f-ed first) because make finds that: No need to remake target `funs.h'. No need to remake target `key.c'. Prerequisite `key.c' is newer than target `doc.c'. Must remake target `doc.c'. % make -v GNU Make 3.81 I'll look on other systems what they think of this.
It looks pretty much as if the precision of Solaris/ZFS is becoming the problem here: File: `info/key.c' Access: 2007-12-01 12:34:49.112744553 +0100 Modify: 2007-12-01 12:34:49.222475429 +0100 Change: 2007-12-01 12:34:49.222475429 +0100 File: `info/doc.c' Access: (0644/-rw-r--r--) Uid: ( 501/ ruurd) Gid: ( 3/ sys) Access: 2007-12-01 12:34:49.112714122 +0100 Modify: 2007-12-01 12:34:49.222445762 +0100 Change: 2007-12-01 12:34:49.222445762 +0100 Indeed key.c is newer than doc.c. On FreeBSD/UFS it is not due to a lower precision: File: `info/key.c' Access: 2007-12-01 12:11:56.000000000 +0100 Modify: 2007-12-01 12:11:09.000000000 +0100 Change: 2007-12-01 12:11:09.000000000 +0100 File: `info/doc.c' Access: 2007-12-01 12:11:53.000000000 +0100 Modify: 2007-12-01 12:11:09.000000000 +0100 Change: 2007-12-01 12:11:09.000000000 +0100 The precision on Linux/ext3 appears to be the same, however over NFS from Solaris/ZFS it reports the same precision as on Solaris for at least ctime, which could explain why the original reporter reported this issue on a Linux system. On Darwin/HFS+ also the same precision as on FreeBSD/UFS is seen, which explains why it compiles fine there. Again via NFS access to Solaris/ZFS the high precision is observed. I have no clue how to fix this at all.
Created attachment 137449 [details, diff] high time precision patch The attached patch fixes the issue on Solaris by using a touch -r to make sure the generated files all have exactly the same time stamp. On systems with a lower precision this patch could also help for the border case where the files are generated just on the flip of the second. @Mike: is this better?
no, of course that isnt a good idea :p look at makedoc.c:main() and see if re-ordering the must_fopen() and/or fclose() calls helps
Created attachment 137494 [details, diff] 2nd try to get the times correct You're right. How about this patch? Alternative would be to change the depend order in the Makefile.
i'd insert a comment above the fopen/fclose lines like: /* the order of these files depends exactly on the order in the Makefile.in */ you going to send this to the upstream automake guys or shall i ? you're right that reordering the Makefile.in dependencies would probably work just the same ... both places should have a comment saying they depend explicitly on the other
err, upstream texinfo guys, not automake guys of course ...
Assuming you have the contacts with upstream, I think it's best if you send it upstream. You want me to fix up the patch to include a comment at both places?
i dont have any contacts ... i'd just post the patch at the relevant bug tracker and/or e-mail the relevant mailing list yes, please patch both files with a comment ... then you can commit the patch or i'll do it, doesnt matter to me
Fixed per url: http://article.gmane.org/gmane.comp.tex.texinfo.bugs/3881 (applied upstream) Thanks all!
thanks for getting it sorted ... were you going to commit this to the tree or just wait for the next release ?
If you prefer, I can add the patch to gentoo-x86 as well. However, since gentoo-x86 mainly targets systems that have a very low chance of seeing this bug, I refrained from doing so. Besides that, I don't like messing with base-system packages unless I got explicit permission to do so ;)
it's your call ... nothing in the common Gentoo world is affected by this
