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

["Dmitry Yu. Bolkhovityanov via Tech-talk" <tech-talk at aps.anl.gov>]

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