Dave Korn <dave.korn.cygwin <at> googlemail.com> writes: > > I don't speak M4, and anyway this is just a distraction from the main job > I was trying to do at the time, so this is as far as I've looked at it. I've > kept the autom4te.cache dirs and trace logs around, in case they'll be of any > help.
Never mind my earlier reluctance to look at your trace. You snipped just enough for me to know exactly what the failure is: > m4trace:configure.ac:449: -1- id 107675: lt_if_append_uniq(...) -> [m4_ifdef ([lt_decl_varnames], > [m4_bmatch([, ][]m4_defn([lt_decl_varnames])[, ], [, ][]m4_re_escape ([macro_version])[, ], > [], > [m4_append([lt_decl_varnames], [macro_version], [[, ]]) Oops. m4_append was undocumented in 2.60, then changed semantics in autoconf 2.62. Newer libtool works around the semantic change by using lt_append, not m4_append: http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=5b560bd But you still have the definition of lt_if_append_uniq from older libtool, which doesn't work with newer autoconf. I guess this means no one has yet identified this as one of the fixes that needs to be imported as part of future- proofing the gcc tree to make the eventual transition to newer autotools easier. Do you feel like opening a gcc incident with this email chain as the starting point? -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
