Hi Michael,
On Thu, 11 May 2023, Michael Davidsaver wrote:
On 5/11/23 01:38, Dmitry Yu. Bolkhovityanov via Tech-talk wrote:
...
The next step will be to find which git commit bringed this change.
https://github.com/epics-base/epics-base/pull/254
May I suggest a small addition to your patch? It modifies behaviour for old, non-__has_include()-enabled compilers, thus eliminating a regression (and solving Mark Rivers' problem mentioned in https://epics.anl.gov/core-talk/2022/msg00385.php). The idea is to fall back to old readline detection method instead of defaulting to =EPICS (the whole file is attached):
% diff -ub ./base-7.0.7/configure/toolchain.c{.orig,}
--- ./base-7.0.7/configure/toolchain.c.orig 2022-09-08 01:50:35.000000000 +0700
+++ ./base-7.0.7/configure/toolchain.c 2023-05-13 13:12:20.967486783 +0700
@@ -45,5 +45,7 @@
COMMANDLINE_LIBRARY ?= EPICS
# endif
#else
-COMMANDLINE_LIBRARY ?= EPICS
+COMMANDLINE_LIBRARY ?= $(strip $(if $(wildcard \\
+ $(firstword $(READLINE_DIR) $(GNU_DIR))/include/readline/readline.h), \\
+ READLINE, EPICS))
#endif
The detection snippet was copied from configure/os/CONFIG_SITE.Common.linux-arm as it tries 2 dirs instead of 1 as most other places do.
I've tested it on CentOS-7.3 (gcc version 4.8.5 20150623) and now libCom.so.3.22.0 does get a libreadline.so dependency.
(However, as I don't have access to neither vxWorks/RTEMS nor MinGW etc., can't check behaviour on such systems.)
The only oddity which puzzled me is integration of commandline editing
into libCom -- that looks completely out of place.
Hardly the only historical oddity in a ~30 year old code base.
(at least we don't link in libX11 ...)
As funny as linking in libX11 looks, there could be a reasonable scenario for libXt: that can be used as application's main loop, taking care of file descriptors and timeouts, similarly to fdManager. :)
With best regards,
Dmitry
