Fix quoting of AC_LANG_SOURCE arguments

Some changequote invocations in the *.m4 files looked wrong. And indeed a bug was lurking in there, in printf.m4. 2020-08-16 Bruno Haible Fix quoting of AC_LANG_SOURCE arguments. * m4/printf.m4 (gl_PRINTF_ENOMEM): Fix an m4 quoting bug in the GL_NOCRASH expansion.

[PATCH] nstrftime: be more predictable about errno

This aligns nstrftime better with draft POSIX 202x strftime. * lib/nstrftime.c: Include errno.h. (width_add, __strftime_internal): Set errno on failure, and preserve it on success. Check for mktime_z failure. * modules/nstrftime (Depends-on): Add errno. * modules/nstrftime-tests (Depends-on): Add

Re: improve clang support (29)

Gisle Vanem wrote: > > clang on Windows, by default, does not link with '-loldnames' (like mingw > > and > > MSVC 14 do). > > You mean when using 'lld-link'? No. I'm using 'clang', and 'clang' happens to use the link.exe from the MSVC installation directory (regardless whether I have set an envi

improve clang support (32)

With MSVC/clang, I'm seeing this configure output: checking whether realpath works... mkdir: cannot create directory 'conftest.d': File exists no The .d files contain dependency information, apparently generated by clang. So, we need to clean up before starting the test. 2020-08-15 Bruno

improve clang support (31)

With MSVC/clang, the configure output contains: checking whether C symbols are prefixed with underscore at the linker level... /usr/bin/grep: conftest.asm: No such file or directory no This patch fixes it. 2020-08-15 Bruno Haible Determine asm output option and filename suffix

Re: improve clang support (29)

Bruno Haible wrote: clang on Windows, by default, does not link with '-loldnames' (like mingw and MSVC 14 do). You mean when using 'lld-link'? One can use 'link.exe' with 'clang-cl' with no problem. And is IMHO better than clang's linker. Why assume what linker *must* be used?

improve clang support (30)

On MSVC/clang, the printf.m4 tests report: checking whether printf supports the zero flag correctly... no checking whether printf supports large precisions... no This occurs because clang inlines sprintf calls, and apparently still has the same bug as we noticed for FreeBSD in 2007.

frexpl: Fix configuration test result on MSVC

The MSVC compiler does not like to compile the autoconf test for frexpl: error C2124: divide or mod by zero 2020-08-15 Bruno Haible frexpl: Fix configuration test result on MSVC. * m4/frexpl.m4 (gl_FUNC_FREXPL_WORKS): Avoid a division by a constant zero. diff --git

improve clang support (29)

clang on Windows, by default, does not link with '-loldnames' (like mingw and MSVC 14 do). This means that programs that use open(), close(), etc. will get link errors by default. For more than 10 years, Microsoft has been deprecating these function names: access chdir chmod close creat dup dup2

improve clang support (26)

With clang on native Windows (i.e. the MSVC header files), #include #include works fine, but #include #include and #include #include produce an error. The effect is that our configure test reports checking for working stdnoreturn.h... yes but then the compilation of the

improve clang support (28)

With clang on Windows, I get warnings such as round.c:70:10: warning: unknown pragma ignored [-Wunknown-pragmas] # pragma fenv_access (off) ^ 1 warning generated. This patch fixes them. 2020-08-15 Bruno Haible Fix "unknown pragma ignored" warnings with clang on nati

improve clang support (27)

With clang on native Windows, I see these errors in the compilation of test-pthread-c++.cc: ../gllib\pthread.h:1023:19: error: use of undeclared identifier 'pthread_create'; did you mean 'gnulib::pthread_create'? _GL_CXXALIASWARN (pthread_create); ^~