I have attached relevant part from config.log in gziped config.txt. I think the reason may be very outdated m4/gettext.m4:
``` # gettext.m4 serial 66 (gettext-0.18.2) ``` Detecting libintl from libiconv-1.18 release, which has: ``` # serial 81 (gettext-0.23) ``` works just fine. If I understand how m4's testsutre works, it runs `check-them` shell script which runs m4 and compares output it produces to output it is expected to produce. While some diffs seem harmless, there are cases like: ``` /h/releases/m4-1.4.20/checks/219.improved_f: stderr mismatch --- m4-tmp.1210759/m4-xerr 2025-06-05 22:30:54.988764500 +0900 +++ m4-tmp.1210759/m4-err 2025-06-05 22:30:54.954534500 +0900 @@ -1 +1,2 @@ -I:\gnu-libs-with-msvc\x86_64-msvc-windows\stage2\builddir\m4\src\m4.exe:stdin:6: bad expression in eval (bad input): (a) <= (b) +m4.exe:stdin:1: cannot undivert `forloop2.m4': No such file or directory +m4.exe:stdin:2: cannot open `forloop2.m4': No such file or directory ``` I can attach gziped output from `make check` (without gnulib's tests). - Kirill Makurin ________________________________ From: Eric Blake <[email protected]> Sent: Thursday, June 5, 2025 10:21 PM To: Kirill Makurin <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Small typo result in build error with MSVC Adding gnulib On Thu, Jun 05, 2025 at 10:35:36AM +0000, Kirill Makurin wrote: > Hello, > > I tried to build m4-1.4.20 release with MSVC. > > Build fails with the following diagnostic (from many files): > > ``` > H:\releases\m4-1.4.20\src\builtin.c(1472): error C2065: 'OBSTACK_CPTR': > undeclared identifier > H:\releases\m4-1.4.20\src\builtin.c(1472): error C2064: term does not > evaluate to a function taking 0 arguments > ``` > > It comes from gnulib's lib/obstack.h.in, line 593: > > ``` > (((_OBSTACK_CPTR) (h)->chunk < (OBSTACK_CPTR) (h)->temp.tempptr > ``` > > where _OBSTACK_CPTR mistakenly referenced as OBSTACK_CPTR. Adding an > underscore fixes the build error. Thanks for the report. > > I also noticed that configure fails to locate/use installed libintl: > > ``` > checking for GNU gettext in libc... no > checking for iconv... (cached) yes > checking for working iconv... (cached) yes > checking how to link with libiconv... -liconv > checking for GNU gettext in libintl... no > checking whether to use NLS... no > ``` Is there a relevant snippet of config.log that shows why configure was unable to use your installed library? Is it something you can work around by priming appropriate cache variables during the configure run? > > Please let me know if you are interested in result of `make check`. Did it pass, or did you see particular failures? -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
config.txt.gz
Description: config.txt.gz
