Re: Why does libca.so depend on libreadline.so?

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Dmitry,

• What distro is it?  
  

corvette:local/epics-devel/base-7.0.7>more /etc/centos-release

CentOS Linux release 7.9.2009 (Core)

> 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).

I believe you that libCom.so in Centos 7.3 had no dependency on readline.  However, did you actually check that an IOC built with that version had functioning command line recall?  In my experience it will not.

Mark

---

From: Dmitry Yu. Bolkhovityanov <D.Yu.Bolkhovityanov at inp.nsk.su>
Sent: Friday, May 12, 2023 10:09 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: Andrew Johnson <anj at anl.gov>; Simon Rose <Simon.Rose at ess.eu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Why does libca.so depend on libreadline.so?

 

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
>
>