Experimental Physics and
Industrial Control System

"Dmitry Yu. Bolkhovityanov via Tech-talk" <tech-talk at aps.anl.gov> · Fri, 12 May 2023 22:09:03 +0700 (+07)

Hi Mark,

What distro is it? I performed checks on CentOS-7.3 and it had shown

no dependency in 7.0.7 (all releases were built in a series via shell's

"for" loop, so no place for a human error).

Additionaly, 7.0.7 on an esoteric Linux distro on another CPU architecture

also shows dependency presence.

Maybe that's because Michael's check via

"__has_include(<readline/readline.h>)" behaves somehow differently in

CentOS-7 and considers readline absent.

...damn -- I understood! CentOS-7.3 gcc version is 4.8.5, which doesn't

support the __has_include() builtin (I couldn't find which GCC version it

appeared in, but "gcc -E -dM - </dev/null|grep include" doesn't show it,

while gcc-8.5.0 does).

An intermediate conclusion: the "__has_include(<readline/readline.h>)"

patch did introduce a regression on old platforms: the new mechanism

doesn't work and defaults to "COMMANDLINE_LIBRARY = EPICS", while the old

detection was removed from configure/os/CONFIG_SITE.* files.

Anyway, the situation looks more clear: the libCom.so dependency on a

commandline-editing facility DOES present in both 3.15 and 7.0 branches.

So, the correct solution will be to get "iocsh core" out of libCom.

Probably not a simple task, but at least observable and no magic involved

:)

With best regards,
Dmitry

On Fri, 12 May 2023, Mark Rivers wrote:

I find that libCom does depend on libreadline for base 7.0.5, 7.0.6.1, and 7.0.7.

corvette:/usr/local/epics-devel>ldd base-7.0.5/lib/linux-x86_64/libCom.so
       linux-vdso.so.1 =>  (0x00007ffd3ed4d000)
       libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f654a0f4000)
       libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f6549eae000)
       librt.so.1 => /lib64/librt.so.1 (0x00007f6549ca6000)
       libdl.so.2 => /lib64/libdl.so.2 (0x00007f6549aa2000)
       libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f654979a000)
       libm.so.6 => /lib64/libm.so.6 (0x00007f6549498000)
       libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6549282000)
       libc.so.6 => /lib64/libc.so.6 (0x00007f6548eb4000)
       /lib64/ld-linux-x86-64.so.2 (0x00007f654a585000)
       libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f6548c8a000)

corvette:/usr/local/epics-devel>ldd base-7.0.6.1/lib/linux-x86_64/libCom.so
       linux-vdso.so.1 =>  (0x00007ffc4d5f2000)
       libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe375e9d000)
       libreadline.so.6 => /lib64/libreadline.so.6 (0x00007fe375c57000)
       librt.so.1 => /lib64/librt.so.1 (0x00007fe375a4f000)
       libdl.so.2 => /lib64/libdl.so.2 (0x00007fe37584b000)
       libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fe375543000)
       libm.so.6 => /lib64/libm.so.6 (0x00007fe375241000)
       libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe37502b000)
       libc.so.6 => /lib64/libc.so.6 (0x00007fe374c5d000)
       /lib64/ld-linux-x86-64.so.2 (0x00007fe37632d000)
       libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fe374a33000)

corvette:/usr/local/epics-devel>ldd base-7.0.7/lib/linux-x86_64/libCom.so
       linux-vdso.so.1 =>  (0x00007ffd4d1f4000)
       libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f643e256000)
       libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f643e010000)
       librt.so.1 => /lib64/librt.so.1 (0x00007f643de08000)
       libdl.so.2 => /lib64/libdl.so.2 (0x00007f643dc04000)
       libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f643d8fc000)
       libm.so.6 => /lib64/libm.so.6 (0x00007f643d5fa000)
       libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f643d3e4000)
       libc.so.6 => /lib64/libc.so.6 (0x00007f643d016000)
       /lib64/ld-linux-x86-64.so.2 (0x00007f643e6e6000)
       libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f643cdec000)

________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Simon Rose via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, May 12, 2023 9:09 AM
To: Dmitry Yu. Bolkhovityanov <D.Yu.Bolkhovityanov at inp.nsk.su>; Andrew Johnson <anj at anl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Why does libca.so depend on libreadline.so?

Hi Dmitry -

I do not get the same results as you. When I build various version of EPICS base (e.g. 7.0.4, 7.0.5) for linux-x86_64, libCom also depends on readline at that point. I don't think the change that Michael linked is the source of this dependency.

Cheers,

Simon

On 2023-05-11, 11:09, "Tech-talk on behalf of Dmitry Yu. Bolkhovityanov via Tech-talk" <tech-talk-bounces at aps.anl.gov <mailto:tech-talk-bounces at aps.anl.gov> on behalf of tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:

Hi Andrew,

On Wed, 10 May 2023, Andrew Johnson wrote:

However, a brief investigation had found this had changed in the 7.0.x
between 7.0.2 and 7.0.7: in 7.0.2 the libca.so.4.13.3 does have a
dependency on libreadline, while 7.0.7's libca.so.4.14.2 does NOT.

So, if 7.0.x was refactored to get rid of this dependency, then this
change can probably be back-ported to 3.15.x. A quick inspection of
https://epics.anl.gov/base/R7-0/7-docs/RELEASE_NOTES.html <https://epics.anl.gov/base/R7-0/7-docs/RELEASE_NOTES.html> doesn't show any
traces of this change; probably a "diff -Naur" between sources is
required. I'm not sure my skills are sufficient for this back-porting,
but I'll try.

I suspect that your brief investigation missed the fact that there were
changes to the build system's detection of whether the target has a usable
copy of readline installed, and those changes are almost certainly why some
of your builds linked the libCom shared library with it and others didn't.

I performed checks on a same x86_64 system (CentOS7 with readline-devel
installed (specifically for EPICS3)), so the differences are caused by
7.0.x versions only.

BTW, I've just built all releases between 7.0.2.2 and 7.0.7 to find when
this change happened and it turned out to be the 7.0.7:

b360mc:/tmp/x% ldd base-7.0.6/lib/linux-x86_64/libCom.so.3.20.0 base-7.0.7/lib/linux-x86_64/libCom.so.3.22.0
base-7.0.6.1/lib/linux-x86_64/libCom.so.3.21.0:
linux-vdso.so.1 => (0x00007fffc3def000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0b17fc5000)
libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f0b17d7f000)
^^^^^^^^^^^^^^^^
librt.so.1 => /lib64/librt.so.1 (0x00007f0b17b77000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0b17973000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f0b1766c000)
libm.so.6 => /lib64/libm.so.6 (0x00007f0b1736a000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f0b17154000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0b16d87000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0b18455000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f0b16b5d000)
base-7.0.7/lib/linux-x86_64/libCom.so.3.22.0:
linux-vdso.so.1 => (0x00007ffe65529000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f402824d000)
librt.so.1 => /lib64/librt.so.1 (0x00007f4028045000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4027e41000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4027b3a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4027838000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4027622000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4027255000)
/lib64/ld-linux-x86-64.so.2 (0x00007f40286dd000)

The next step will be to find which git commit bringed this change.

If you don't want your builds of libCom and libCa to depend on readline, you
should ensure that it doesn't get built in by setting
COMMANDLINE_LIBRARY=EPICS in an appropriate CONFIG_SITE* file.

Yes, I finally figured that out. 3.15.9 does include appropriate comments
in configure/os/CONFIG_SITE.Common.linux-x86_64; I wish those were present
in 3.15.6 days when I first met with readline problem, but there was only
a rather misleading "If none of them work, comment them all out to build
without readline support." statement, so I *had* to build libreadline
(which is a rather troublesome beast in itself) and adopted a strong
dislike of it :)

Our default
build configuration is likely to /always/ try to make use of readline if it's
available, since it makes the IOC's shell so much easier to interact with.
That is especially true now that the command-line completion features that
readline provides have been integrated into iocsh.

Yes, that's understandable.

(I vividly remember the gulf in the convenience of editing the commandline
between bare-metal (be happy if Backspace works) and DOS, and later
between DOS and *NIX with Tab support.)

The only oddity which puzzled me is integration of commandline editing
into libCom -- that looks completely out of place.

With best regards,
Dmitry

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System