Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS
On Jan 17, 2022, at 16:14, Paul Eggert wrote: > That part of Gnulib was introduced in 2013: > > https://lists.gnu.org/r/bug-gnulib/2013-11/msg00045.html > > and as I vaguely recall was in response to this macports ticket: > > https://trac.macports.org/ticket/41033 > I don't know whether the macOS world has moved on and nobody cares about > older Apple releases with the ctype.h bug. If so, we could simplify Gnulib. MacPorts itself still runs on Mac OS X 10.4 and later and we do still have a number of users using older systems. More so than with other operating systems, I think, Mac users care about support for older OS versions because Apple often arbitrarily decides that they will not allow newer OS versions to be installed on older computers. So my 2 cents is that I would appreciate it if gnulib maintained compatibility with older systems. I said the same in the recent thread on this mailing list where we were trying to address a gnulib bug with determining the max path length that affects Mac OS X 10.5 systems.
Re: undefined references to "rpl_fclose" and "rpl_fflush"
Bjarni Ingi Gislason wrote: > Software: groff > > Adding some gnulib modules to "bootstrap.conf" after checking with > module "posixcheck": Glad to hear that the module 'posixcheck' still works fine! (I haven't actually used it for more than 10 years.) > results in linker errors: > > make[1]: Entering directory '/home/bg/git/groff/build' > CXX src/libs/libdriver/input.o > CXX src/libs/libdriver/printer.o > AR libdriver.a > CXX src/libs/libgroff/libgroff_a-assert.o > CXX src/libs/libgroff/libgroff_a-error.o > CXX src/libs/libgroff/libgroff_a-font.o > AR libgroff.a > CXXLDgrodvi It would be helpful to show the actual link command, not an abbreviation such as "CXXLD". That is, run "make V=1", not "make". > The file "build/libgroff.a" contains these "rpl_" strings: > > rpl_fprintf > rpl_fflush > rpl_fprintf For analyzing a .a file, please use 'nm', not 'strings'. Especially "nm libgroff.a | grep ' T '" and "nm libgroff.a | grep ' U '". > The file "build/libdriver.a" contains these "rpl_" strings > > rpl_fclose > rpl_fclose Likewise. > Compilation is normal if I remove the modules "fclose" and "fflush" > from "bootstrap.conf". It should work also with these modules included. Bruno
Re: license: comma or semicolon?
On Tue, Jan 04, 2022 at 12:28:34AM +0100, Bernhard Voelker wrote: > On 1/3/22 01:17, Mike Frysinger wrote: > > according to gnu.org, it should be a comma. > > https://www.gnu.org/licenses/gpl-3.0.html#howto > > The attached would change it, and shows how the change was done: > > Subject: [PATCH] license: fix GPLv3 texts to use a comma instead of > semicolon. > > See: https://www.gnu.org/licenses/gpl-3.0.html#howto > Run: > $ git grep -l 'Foundation; either version 3' \ > | xargs sed -i '/Foundation; either version 3/ s/n; e/n, e/' > > * All files using GPLv3: Adjust via the above command. > > I'm reluctant because that will most probably also change files auto-updated > from other projects. Just for the record, I've applied the following patch to GNU config in your name about two weeks ago: https://git.savannah.gnu.org/cgit/config.git/commit/?id=03087cbd5161db0ff94e578b02d318d0bba2742d -- ldv
Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS
On Mon, Jan 17, 2022 at 5:14 PM Paul Eggert wrote: > > On 1/17/22 10:37, Reuben Thomas wrote: > > > "extern-inline" copies a stanza of code into > > config.h. That code includes a test of the preprocessor macro > > "__header_inline". That macro is defined in a system header on macOS. > > When config.h is #included, no other header has been included. > > Therefore, the symbol will never have been defined at the point where > > it is tested in config.h. Therefore, the test will always fail. > > Thanks for explaining more. That part of Gnulib was introduced in 2013: > > https://lists.gnu.org/r/bug-gnulib/2013-11/msg00045.html > > and as I vaguely recall was in response to this macports ticket: > > https://trac.macports.org/ticket/41033 > > Apparently until now nobody tested that part of Gnulib to make sure that > it omits the workaround on newer Apple platforms where the underlying > bug has been fixed. (The underlying bug was that defined > static functions to implement isalpha etc. on OS X 10.8 and earlier in > C, but the C standard does not allow this and using static functions > broke some GNU code.) > > Although the workaround still functions on current macOS, it's better to > use proper inline functions when available so I installed the attached > patch into Gnulib. Please give it a try. > > I don't know whether the macOS world has moved on and nobody cares about > older Apple releases with the ctype.h bug. If so, we could simplify Gnulib. I think the version of OSX to test is OS X 10.5. I've got a PowerMac running it, if interested. Send over your SSH public key for access. Jeff
Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS
On Mon, 17 Jan 2022 at 22:14, Paul Eggert wrote: > > Although the workaround still functions on current macOS, it's better to > use proper inline functions when available so I installed the attached > patch into Gnulib. Please give it a try. Thanks, I will. > I don't know whether the macOS world has moved on and nobody cares about > older Apple releases with the ctype.h bug. If so, we could simplify Gnulib. Support for MacOS 10.8 (the last version without the fix) ended in November 2015 according to Wikipedia. The most recent Apple hardware that wouldn't run anything newer than 10.8 is from 2006. -- https://rrt.sc3d.org
Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS
On 1/17/22 10:37, Reuben Thomas wrote: "extern-inline" copies a stanza of code into config.h. That code includes a test of the preprocessor macro "__header_inline". That macro is defined in a system header on macOS. When config.h is #included, no other header has been included. Therefore, the symbol will never have been defined at the point where it is tested in config.h. Therefore, the test will always fail. Thanks for explaining more. That part of Gnulib was introduced in 2013: https://lists.gnu.org/r/bug-gnulib/2013-11/msg00045.html and as I vaguely recall was in response to this macports ticket: https://trac.macports.org/ticket/41033 Apparently until now nobody tested that part of Gnulib to make sure that it omits the workaround on newer Apple platforms where the underlying bug has been fixed. (The underlying bug was that defined static functions to implement isalpha etc. on OS X 10.8 and earlier in C, but the C standard does not allow this and using static functions broke some GNU code.) Although the workaround still functions on current macOS, it's better to use proper inline functions when available so I installed the attached patch into Gnulib. Please give it a try. I don't know whether the macOS world has moved on and nobody cares about older Apple releases with the ctype.h bug. If so, we could simplify Gnulib.From 55d5e977bc9d05d67221c56a9c65e4bf11828793 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 17 Jan 2022 14:03:01 -0800 Subject: [PATCH] extern-inline: improve macOS port * m4/extern-inline.m4 (gl_EXTERN_INLINE): Define HAVE___HEADER_INLINE at configure-time, so that config.h knows the workaround is not needed even though ctype.h has not yet been included. This lets the compiler use extern inline functions on newer macOS platforms, instead of static inline. Problem reported by Reuben Thomas in: https://lists.gnu.org/r/bug-gnulib/2022-01/msg00130.html --- ChangeLog | 11 +++ m4/extern-inline.m4 | 19 +-- 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 33944f44b8..c5eebe4872 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2022-01-17 Paul Eggert + + extern-inline: improve macOS port + * m4/extern-inline.m4 (gl_EXTERN_INLINE): + Define HAVE___HEADER_INLINE at configure-time, so that config.h + knows the workaround is not needed even though ctype.h has not yet + been included. This lets the compiler use extern inline functions + on newer macOS platforms, instead of static inline. + Problem reported by Reuben Thomas in: + https://lists.gnu.org/r/bug-gnulib/2022-01/msg00130.html + 2022-01-17 Bruno Haible xstrtol: Trim dependencies. diff --git a/m4/extern-inline.m4 b/m4/extern-inline.m4 index 2e914dbc07..8a12bddd57 100644 --- a/m4/extern-inline.m4 +++ b/m4/extern-inline.m4 @@ -7,7 +7,22 @@ dnl with or without modifications, as long as this notice is preserved. AC_DEFUN([gl_EXTERN_INLINE], [ - AH_VERBATIM([extern_inline], + AC_CACHE_CHECK([whether ctype.h defines __header_inline], +[gl_cv_have___header_inline], +[AC_PREPROC_IFELSE( + [AC_LANG_SOURCE([[#include + #ifndef __header_inline + #error " does not define __header_inline" + #endif +]])], + [gl_cv_have___header_inline=yes], + [gl_cv_have___header_inline=no])]) + if test "$gl_cv_have___header_inline" = yes; then +AC_DEFINE([HAVE___HEADER_INLINE], [1], + [Define to 1 if ctype.h defines __header_inline.]) + fi + + AH_VERBATIM([HAVE___HEADER_INLINE_1], [/* Please see the Gnulib manual for how to use these macros. Suppress extern inline with HP-UX cc, as it appears to be broken; see @@ -54,7 +69,7 @@ AC_DEFUN([gl_EXTERN_INLINE], */ #if (((defined __APPLE__ && defined __MACH__) \ || defined __DragonFly__ || defined __FreeBSD__) \ - && (defined __header_inline \ + && (defined HAVE___HEADER_INLINE \ ? (defined __cplusplus && defined __GNUC_STDC_INLINE__ \ && ! defined __clang__) \ : ((! defined _DONT_USE_CTYPE_INLINE_ \ -- 2.32.0
undefined references to "rpl_fclose" and "rpl_fflush"
Software: groff Adding some gnulib modules to "bootstrap.conf" after checking with module "posixcheck": close dup execvp fclose fdopen fflush fopen freopen malloc-posix nl_langinfo pclose perror pipe-posix popen realloc-posix strerror strsignal strtol tmpfile results in linker errors: make[1]: Entering directory '/home/bg/git/groff/build' CXX src/libs/libdriver/input.o CXX src/libs/libdriver/printer.o AR libdriver.a CXX src/libs/libgroff/libgroff_a-assert.o CXX src/libs/libgroff/libgroff_a-error.o CXX src/libs/libgroff/libgroff_a-font.o AR libgroff.a CXXLDgrodvi /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `text_file::~text_file()': /home/bg/git/groff/build/../src/libs/libgroff/font.cpp:102: undefined reference to `rpl_fclose' /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `assertion_failed(int, char const*, char const*, char const*)': /home/bg/git/groff/build/../src/libs/libgroff/assert.cpp:37: undefined reference to `rpl_fflush' /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `font::scan_papersize(char const*, char const**, double*, double*)': /home/bg/git/groff/build/../src/libs/libgroff/font.cpp:774: undefined reference to `rpl_fclose' /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `do_error_with_file_and_line(char const*, char const*, int, error_type, char const*, errarg const&, errarg const&, errarg const&)': /home/bg/git/groff/build/../src/libs/libgroff/error.cpp:83: undefined reference to `rpl_fflush' /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `printer::~printer()': /home/bg/git/groff/build/../src/libs/libdriver/printer.cpp:95: undefined reference to `rpl_fflush' /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `do_file(char const*)': /home/bg/git/groff/build/../src/libs/libdriver/input.cpp:1827: undefined reference to `rpl_fclose' /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `do_file(char const*)': /home/bg/git/groff/build/../src/libs/libgroff/font.cpp:102: undefined reference to `rpl_fclose' /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `font::load(bool)': /home/bg/git/groff/build/../src/libs/libgroff/font.cpp:102: undefined reference to `rpl_fclose' /usr/bin/ld: /tmp/ccwhBA9z.ltrans0.ltrans.o: in function `do_error_with_file_and_line(char const*, char const*, int, error_type, char const*, errarg const&, errarg const&, errarg const&)': /home/bg/git/groff/build/../src/libs/libgroff/error.cpp:83: undefined reference to `rpl_fflush' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:7506: grodvi] Error 1 make[1]: Leaving directory '/home/bg/git/groff/build' make: *** [Makefile:6763: all] Error 2 This is both without and with "#include " as the first include statement in "assert.cpp", "error.cpp", "font.cpp", "input.cpp", and "printer.cpp". The file "build/libgroff.a" contains these "rpl_" strings: rpl_fprintf rpl_fflush rpl_fprintf rpl_fflush rpl_fprintf rpl_fprintf rpl_fprintf rpl_fflush rpl_fflush rpl_fclose rpl_fclose rpl_fprintf Urpl_fprintf .gnu.lto_rpl_fprintf.46.a0e291f44b54f74a rpl_fprintf rpl_fprintf rpl_fclose rpl_fclose rpl_fprintf rpl_fprintf The file "build/libdriver.a" contains these "rpl_" strings rpl_fclose rpl_fclose rpl_fflush rpl_fflush Compilation is normal if I remove the modules "fclose" and "fflush" from "bootstrap.conf". -- Bjarni I. Gislason
Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS
On Mon, 17 Jan 2022 at 17:41, Paul Eggert wrote: > > Could you give complete instructions from scratch, to reproduce the > config.h that has this problem? Without that, it'll be hard for us to > understand or fix the problem. Sorry, I've failed to explain the problem clearly (or maybe there's a mistake in my reasoning); it doesn't matter how the config.h is produced. The module "extern-inline" copies a stanza of code into config.h. That code includes a test of the preprocessor macro "__header_inline". That macro is defined in a system header on macOS. When config.h is #included, no other header has been included. Therefore, the symbol will never have been defined at the point where it is tested in config.h. Therefore, the test will always fail. -- https://rrt.sc3d.org
Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS
On 1/17/22 04:50, Reuben Thomas wrote: Please, to help us reproduce the issue and verify a potential fix: How to reproduce the issue? I.e. What did you try to do, and what were the resulting diagnostics? $ gcc -dM -E config.h | grep GL_EXTERN #define _GL_EXTERN_INLINE static _GL_UNUSED #define _GL_EXTERN_INLINE_STDHEADER_BUG Could you give complete instructions from scratch, to reproduce the config.h that has this problem? Without that, it'll be hard for us to understand or fix the problem.
Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS
On Mon, 17 Jan 2022 at 12:37, Bruno Haible wrote: > > Please, to help us reproduce the issue and verify a potential fix: > How to reproduce the issue? I.e. What did you try to do, and what were > the resulting diagnostics? $ gcc -dM -E config.h | grep GL_EXTERN #define _GL_EXTERN_INLINE static _GL_UNUSED #define _GL_EXTERN_INLINE_STDHEADER_BUG These definitions are wrong, since I'm on a recent macOS system (10.15). -- https://rrt.sc3d.org
Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS
Hi Reuben, > The definition of _GL_EXTERN_INLINE relies, on macOS, on > __header_inline, which is not a compiler built-in, but is defined in > sys/cdefs.h. Therefore, __header_inline is not defined when config.h > is included, and the tests always assume, on macOS, that the compiler > is buggy and does not support "extern inline". Please, to help us reproduce the issue and verify a potential fix: How to reproduce the issue? I.e. What did you try to do, and what were the resulting diagnostics? Bruno
_GL_EXTERN_INLINE not defined correctly in config.h for macOS
The definition of _GL_EXTERN_INLINE relies, on macOS, on __header_inline, which is not a compiler built-in, but is defined in sys/cdefs.h. Therefore, __header_inline is not defined when config.h is included, and the tests always assume, on macOS, that the compiler is buggy and does not support "extern inline". -- https://rrt.sc3d.org
xstrtol: Trim dependencies
The module 'xstrtol' does not use any PRI*, SCN* constants. 2022-01-17 Bruno Haible xstrtol: Trim dependencies. * lib/xstrtol.h: Include , not . * modules/xstrtol (Depends-on): Add stdint. Remove inttypes-incomplete. diff --git a/lib/xstrtol.h b/lib/xstrtol.h index e3fe387790..a0159a772a 100644 --- a/lib/xstrtol.h +++ b/lib/xstrtol.h @@ -19,7 +19,8 @@ #ifndef XSTRTOL_H_ # define XSTRTOL_H_ 1 -# include +/* Get intmax_t, uintmax_t. */ +# include # ifndef _STRTOL_ERROR enum strtol_error diff --git a/modules/xstrtol b/modules/xstrtol index d171890f3d..137cc1f5ab 100644 --- a/modules/xstrtol +++ b/modules/xstrtol @@ -10,7 +10,7 @@ m4/xstrtol.m4 Depends-on: assure intprops -inttypes-incomplete +stdint configure.ac: gl_XSTRTOL
Re: [PATCH 2/2] xstrtol: simplify integer overflow checking
Paul Eggert did: > * lib/xstrtol.c: Include intprops.h. > (TYPE_SIGNED): Remove, as intprops.h defines that for us now. > (bkm_scale): Use INT_MULTIPLY_WRAPV instead of checking for > overflow by hand. $ ./gnulib-tool --test --single-configure xstrtol fails: gcc -DHAVE_CONFIG_H -I. -I../../gllib -I.. -DGNULIB_STRICT_CHECKING=1 -g -O2 -MT xstrtol.o -MD -MP -MF .deps/xstrtol.Tpo -c -o xstrtol.o ../../gllib/xstrtol.c ../../gllib/xstrtol.c:44:10: fatal error: intprops.h: No such file or directory 44 | #include "intprops.h" | ^~~~ compilation terminated. make[4]: *** [Makefile:1562: xstrtol.o] error 1 This patch fixes it. 2022-01-17 Bruno Haible xstrtol: Fix compilation error (regression 2022-01-16). * modules/xstrtol (Depends-on): Add intprops. diff --git a/modules/xstrtol b/modules/xstrtol index a765f97452..d171890f3d 100644 --- a/modules/xstrtol +++ b/modules/xstrtol @@ -9,6 +9,7 @@ m4/xstrtol.m4 Depends-on: assure +intprops inttypes-incomplete configure.ac:
Re: [PATCH 2/2] xstrtol: simplify integer overflow checking
On Mon, Jan 17, 2022 at 7:53 AM Paul Eggert wrote: > * lib/xstrtol.c: Include intprops.h. > (TYPE_SIGNED): Remove, as intprops.h defines that for us now. > (bkm_scale): Use INT_MULTIPLY_WRAPV instead of checking for > overflow by hand. Thanks. I've just pushed this, too. xstrtol: remove unnecessary else after return * lib/xstrtol.c (bkm_scale): Drop "else" after return. diff --git a/ChangeLog b/ChangeLog index 2ea372b0e3..ff78fda8f3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2022-01-17 Jim Meyering + + xstrtol: remove unnecessary else after return + * lib/xstrtol.c (bkm_scale): Drop "else" after return. + 2022-01-16 Paul Eggert xstrtol: simplify integer overflow checking diff --git a/lib/xstrtol.c b/lib/xstrtol.c index 6f5a8bef60..3e2efb2a17 100644 --- a/lib/xstrtol.c +++ b/lib/xstrtol.c @@ -52,8 +52,8 @@ bkm_scale (__strtol_t *x, int scale_factor) *x = *x < 0 ? TYPE_MINIMUM (__strtol_t) : TYPE_MAXIMUM (__strtol_t); return LONGINT_OVERFLOW; } - else -*x = scaled; + + *x = scaled; return LONGINT_OK; }
