URL: <https://savannah.gnu.org/support/?110346>
Summary: Revert to looking for yywrap in AC_PROG_LEX Project: Autoconf Submitted by: zackw Submitted on: Fri 30 Oct 2020 09:08:22 PM UTC Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: Commit 29ede6b96feee29c0c477d1659081bbdb82cd8b3 caused AC_PROG_LEX to stop looking for a library that provides yywrap. This broke several packages in a Debian archive rebuild: undefined symbol: yywrap|libmatheval 1.1.11+dfsg-4 undefined symbol: yywrap|snacc 1.3.1-7 undefined symbol: yywrap|splint 1:3.1.2+dfsg-2 undefined symbol: yywrap|tcpxtract 1.0.1-15 undefined symbol: yywrap|wide-dhcpv6 20080615-23 We should go all the way back to the 2.69 behavior, which was to set LEXLIB to -ll or -lfl if that library defines yywrap, but allow AC_PROG_LEX to succeed if neither -ll nor -lfl exists on the system, even if a lex program that doesn't define yywrap would need it. (This behavior was a bug, but people have come to depend on it. See https://savannah.gnu.org/support/index.php?110269 and the thread starting from https://lists.gnu.org/r/autoconf-patches/2020-07/msg00013.html for gory details.) To provide a path away from bug-compatibility, we could add an optional argument to AC_PROG_LEX which can be either [yywrap] or [noyywrap], meaning to look for yywrap and fail configure if it's unavailable, and to not look for yywrap at all, respectively. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/support/?110346> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/