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