Eric Blake <ebb9 <at> byu.net> writes: > > > > $ automake-1.9 --gnits tests/Makefile > > NONE:0: /packages/gnu/bin/m4: `m4_symbols' from frozen file not found in builtin table! > > autom4te: /packages/gnu/bin/m4 failed with exit status: 1 > > automake-1.9: autoconf failed with exit status: 1 > > make: *** [Makefile.in] Fehler 1 > > > > I had m4-1.4o installed at the same place earlier. Even worse than I thought: http://cvs.savannah.gnu.org/viewcvs/m4/src/freeze.c? rev=1.1.1.4&root=m4&only_with_tag=m4-1_4o&view=markup shows that m4-1.4o is 6 years old, added new builtins, but stuck with format version 1. Therefore, the frozen files mention that on reload, these new builtins should be instantiated, and m4-1.4.x can parse the file but does not know what to do with it. It wasn't until post m4-1.4o that frozen file format 2 was created (current m4 CVS has been known by the name m4-1.4p and/or 1.9a, but no snapshot release has been made since m4-1.4o); where m4 1.4.x can't even parse the file. Would it be worth teaching m4 1.4.5 and 2.0 that if an unknown builtin is encountered in the frozen file, but then is never used in the subsequent input, that it can be safely ignored? I think that this is doable by inventing a placeholder builtin that is installed any time an unknown builtin is encountered during reload rather than the current behavior of erroring out during reload; the placeholder will cause m4 to error if expanded, but should allow m4 1.4.5 to use the format 1 frozen file created by m4 1.4o as long as the problem macro is never used. On the other hand, would it be worth teaching m4sugar that if a frozen file starts with the first non-comment line of V2, but the underlying m4 is version 1.4.x, that it should imply --melt since the frozen file cannot be parsed by m4? This would only help with CVS or m4 2.0 created frozen files being loaded by m4 1.4.x (since m4 1.4o didn't use version 2). But that sounds like something that can wait for post autoconf-2.60, if it is needed at all. -- Eric Blake _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
