|
| From: | Aaron Vose |
| Subject: | RE: Bug report for readline-8.2 header file issues. |
| Date: | Sat, 24 Jun 2023 16:04:39 +0000 |
|
Readline Maintainers, Ah, I think your site mentioned you may like to have some information about the environment I was running this all in. Details follow: prompt> uname -a Linux lvaaccess8 4.18.0-425.3.1.el8.x86_64 #1 SMP Fri Sep 30 11:45:06 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux prompt> lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch Distributor ID: RedHatEnterprise Description: Red Hat Enterprise Linux release 8.7 (Ootpa) Release: 8.7 Codename: Ootpa prompt> lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 6 On-line CPU(s) list: 0-5 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 6 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz Stepping: 7 CPU MHz: 2593.905 BogoMIPS: 5187.81 Hypervisor vendor: VMware Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 25344K NUMA node0 CPU(s): 0-5 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq
ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed
adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat pku ospke avx512_vnni md_clear flush_l1d arch_capabilities Cheers, ~Aaron Vose From: Aaron Vose
Readline Maintainers, Summary: I think I found a (minor) bug in readline 8.2; details follow, and “config.h” is attached. Things build fine, and I can use the library, but some of the header files that are installed with “make && make install” have some issues in them
which I will describe in more detail below. One of the issues I describe below appears to be a genuine bug you probably care about. The problems manifests by including the readline library header file “readline.h” and using “-Werror -Wstrict-prototypes” with
GCC when building a user program, which causes the build to fail. I found the following readline page: https://tiswww.case.edu/php/chet/readline/rltop.html I downloaded readline from the following link: http://git.savannah.gnu.org/cgit/readline.git/snapshot/readline-master.tar.gz I then extracted the tarball (readline 8.2) and ran the following commands to build the library: export CC=/dept/Boston/avose/riscv/tools/install/riscv-gnu/bin/riscv64-unknown-linux-gnu-gcc ./configure --prefix /dept/Boston/avose/riscv/tools/install/riscv-readline --disable-shared --host=riscv64-unknown-linux-gnu --with-curses I know the above is a cross-compile to RISCV, but I don’t think this problem is specific to the ISA, as I’ve seen the exact same issues with ARM installs of readline 8.2 as well. The issue comes from two places in the header files. One
(1) is, I think, an actual issue you want to know about and probably want to fix, the other (2) is probably a more minor thing, but you might still want to know about it, and may want to think about a fix for it. (1) This first issue may actually be a problem you care about. What happens is that “readline.h” contains the following code, which in and of itself isn’t the issue, this is just where the compiler warning / error initially comes from:
extern int rl_message (const char *, ...) __attribute__((__format__ (printf, 1, 2))); #else extern int rl_message (); #endif The configure process did find “stdarg.h” as can be seen in the attached “config.h” file: /* Define if you have the <stdarg.h> header file. */ #define HAVE_STDARG_H 1 However, the “readline.h” file in the install location uses the second prototype: “extern int rl_message ();”. It should instead be using the first one: “extern int rl_message (const char *, ...) __attribute__((__format__
(printf, 1, 2)));”. This is caused by an issue in a file included by “readline.h” called “rlstdc.h”. The problematic code in “rlstdc.h” follows: #if defined (__STDC__) && defined (HAVE_STDARG_H) # define PREFER_STDARG # define USE_VARARGS #else # if defined (HAVE_VARARGS_H) # define PREFER_VARARGS # define USE_VARARGS # endif #endif During the build process, this is fine because “HAVE_STDARG_H” is defined. This then causes “PREFER_STDARG” and “USE_VARARGS” to be defined. So, in the build process, the correct prototype for “rl_message” is used: “extern int rl_message
(const char *, ...) __attribute__((__format__ (printf, 1, 2)));”. However, when user programs include “readline.h” and try to build, “HAVE_STDARG_H” is not defined, and the wrong prototype for “message” is used: “extern int rl_message ();”. This is because
the check for “HAVE_STDARG_H” has been “leaked” out of the build environment into the standard installed readline header files. I don’t think the installed header files should have a check for “HAVE_STDARG_H” in them. This seems like an actual bug, and it
should probably be fixed. My solution here was a hack. I did the following to resolve the error: //!!avose: HAVE_STDARG_H was defined during configure, but this macro is not
//!!avose: included anywhere in the include files for users of readline.
//!!avose: Thus, this edit includes it below. This is needed to avoid issues
//!!avose: from "-Werror=strict-prototypes" #ifndef HAVE_STDARG_H #define HAVE_STDARG_H #define AVOSE_FIX_HAVE_STDARG_H #endif #if defined (__STDC__) && defined (HAVE_STDARG_H) # define PREFER_STDARG # define USE_VARARGS #else # if defined (HAVE_VARARGS_H) # define PREFER_VARARGS # define USE_VARARGS # endif #endif #ifdef AVOSE_FIX_HAVE_STDARG_H #undef HAVE_STDARG_H #undef AVOSE_FIX_HAVE_STDARG_H #endif (2) This second issue is something you may not care about as much. The second issue is another place where compiling a user program that includes “readline.h” is an issue combined with “-Werror -Wstrict-prototypes”. In this second issue, the
problem is in the header file “rltypedefs.h”. The section containing the issue is as follows: #if defined(__GNUC__) || defined(__clang__) typedef int Function () __attribute__((deprecated)); typedef void VFunction () __attribute__((deprecated)); typedef char *CPFunction () __attribute__((deprecated)); typedef char **CPPFunction () __attribute__((deprecated)); #else typedef int Function (); typedef void VFunction (); typedef char *CPFunction (); typedef char **CPPFunction (); #endif These prototypes don’t actually appear to be used anywhere by user programs compiling and linking with readline, and they are an error with “-Werror -Wstrict-prototypes”. My solution here was to just disable this whole block of code with
“#if 0” as shown below. You may not care too much about this, I suppose, just mentioning it. //!!avose: The following types aren't needed anywhere I can see #if 0 #if defined(__GNUC__) || defined(__clang__) typedef int Function () __attribute__((deprecated)); typedef void VFunction () __attribute__((deprecated)); typedef char *CPFunction () __attribute__((deprecated)); typedef char **CPPFunction () __attribute__((deprecated)); #else typedef int Function (); typedef void VFunction (); typedef char *CPFunction (); typedef char **CPPFunction (); #endif #endif It would be wonderful if someone could take a look at these issues, and possible fix them upstream so that others might avoid the problems that I’ve been hitting here. Thanks so much for your time. Thanks much, ~Aaron Vose |
| [Prev in Thread] | Current Thread | [Next in Thread] |