Hi Eric, * Eric Blake wrote on Fri, Jun 16, 2006 at 03:30:02PM CEST: > According to Ralf Wildenhues on 6/16/2006 1:33 AM: > > > > 1) The modules/gnu.la library has the global unprefixed symbol `format'. > > This looks like a bug to me. > > > > 2) modules/m4.la has the global symbol m4_sysval, so has the m4_ prefix > > but not the m4_LTX_m4_ prefix. > > But you didn't provide a patch for these issues?
Right. I may look into it, but not at this point. > > 3) Automake creates build tree directory rules for the targets it writes > > the rules for (the .dirstamp stuff), but not for manually written rules; > > this needs to be done for doc/m4.1 (for a VPATH build). Patch below, > > written not to depend on the Automake internal detail .dirstamp. > > Thanks for catching that; I don't have easy access to a non-GNU make for > VPATH testing. Erm, this happens with GNU make as well. Just try a new build VPATH build tree. I haven't started testing non-GNU make implementations, except for pmake (which is harmless by some means). > > 4) GCC 4.0 has dropped the cast-as-lvalue extension, needing a change in > > src/stackovf.c. Patch below. > > But why do we need the cast at all? Don't all pointers automatically > promote to void*? To avoid a warning, casting from const-pointer to non-const void pointer, I think. > > 5) GCC 4.1 uncovered a potential bug in reload_frozen_state: with > > suitable settings M4ERROR may not exit the program but suppress the > > warning[...] > Indeed, there's a bigger set of issues here, and it affects 1.4.x as well > (although I'm less inclined to change status quo on the 1.4.x series). > GNU Coding Standards state that error messages should be > > program:file:line: message > > But M4ERROR is doing > > file:line: program: Message Oh, I didn't even notice that... Cheers, Ralf _______________________________________________ M4-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/m4-patches
