On Wed, Dec 16, 2020 at 12:22 PM Ross Burton <ross@xxxxxxxxxxxxx> wrote: > All through the 2.70 prelease cycle I was periodically running builds > of OpenEmbedded with the snapshots as they were released. As we > autoreconf by default this was great at shaking out some bugs in both > packages and autoconf itself. However, I see that in between the > Release Candidate and the final release a large breaking change to C > version detection was integrated that basically means that any > software using gnulib needs to update? I assume this is referring either to https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=131d8c69f31dc6fc8dc93abe1096d52d1fe19fd3 or https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=d132ea0278f574fbb3c8d433ea094e36ece73ba1 ? Neither was intended to be a breaking change (one of them moved a lot of code around, but didn't _change_ it all that much) but unintended consequences are a way of life for this project... First, could you please test whether the problem is already fixed in branch-2.70? The release went out with an embarrassing typo in this code. I was waiting to hear back from the automake people about some problems running their testsuite with 2.70, that may or may not need a fix in autoconf, before cutting a 2.70.1, but I can push my schedule for that up a little if it'll help you. Second, assuming the problem is *not* already fixed, it would be really helpful to know which of the above two commits introduced the problem (or if it was neither of them, which commit 'git bisect' fingers), to see a config.log from one of the broken builds, and to know exactly what version of which compiler is in use and whether this is a cross-compilation that breaks. I am snowed under with the day job right now and will not be able to poke at it myself until the weekend. zw
