When I execute bc on the shell I get:
bc: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
Under /usr/lib/ there is just a libreadline.so.8, so I made a copy of libreadline.so.8 and renamed it to libreadline.so.6
Now bc is working again. I use bc in a cron script and have the feeling it is since the last update.
Is this just on my system? Anyone can confirm this on his system?
I only have libreadline.so.8 on my CU167 system but I donāt get the error when running bc.
The last time an update of bc was done was in 2017 and the last update to readline was in April 2021.
Which Core Update version are you running?
If you run the following command on the command line what result do you get.
ldd /usr/bin/bc
and similarly for
ldd /usr/bin/fcrontab
I get the following:-
linux-vdso.so.1 (0x00007ffd57323000)
libfl.so.2 => /usr/lib/libfl.so.2 (0x00007faf992ed000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007faf99293000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007faf9921a000)
libc.so.6 => /lib/libc.so.6 (0x00007faf99012000)
libm.so.6 => /lib/libm.so.6 (0x00007faf98f2b000)
/lib64/ld-linux-x86-64.so.2 (0x00007faf992f9000)
which shows libreadline.so.8 library being linked. I suspect your will have libreadline.so.6 but I donāt understand why because the libraries should have got updated in April 2021 when readline was updated.
The reason that you only see this now is that in CU167 old libraries, files etc were cleaned out and libreadline.so.5 and libreadline.so.6 were ones that were removed.
This also indicates that you are on CU167.
It will be interesting to see if the links for both bc and fcrontab libreadline are the same. If yes then fcrontab should also be having error messages die to missing libreadline.so.6
Will wait to hear from you on the library links for bc and fcrontab
ldd /usr/bin/bc
linux-vdso.so.1 (0x00007ffdec5fd000)
libfl.so.2 => /usr/lib/libfl.so.2 (0x00007c47aea00000)
libreadline.so.6 => /usr/lib64/libreadline.so.6 (0x00007c47aed55000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007c47aecdc000)
libc.so.6 => /lib/libc.so.6 (0x00007c47ae7f8000)
libm.so.6 => /lib/libm.so.6 (0x00007c47ae711000)
/lib64/ld-linux-x86-64.so.2 (0x00007c47aedb6000)
ldd /usr/bin/fcrontab
linux-vdso.so.1 (0x00007fff75999000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x000076ebdb9c1000)
libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x000076ebdb98a000)
libc.so.6 => /lib/libc.so.6 (0x000076ebdb782000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x000076ebdb709000)
/lib64/ld-linux-x86-64.so.2 (0x000076ebdba22000)
And yes Iām on CU167
pakfire status
core-list.db 100.00% |=============================>| 903.00 B
Core-Version: 2.27-x86_64
Core-Update-Level: 167
Last update: 8d 12h 42m 46s ago
Last core-list update: 9h 40m 4s ago
Last server-list update: 9h 40m 5s ago
Last packages-list update: 9h 40m 4s ago
Core-Update available: no
Package-Updates available: 0
Reboot required: no
P.S. Iām pretty sure it worked before 2022-04-27, cause I modified the script then and tested it without error.
I suspected you were going to have that, as if fcrontab was also linked to libreadline.so.6 which had been removed then everyoneās IPFire would not be running fcron which would have been noticed.
So it looks like fcrontab had itās library links updated correctly but bc did not.
It would be good to know if this is only on bc or if other packages that rely on libreadline are also affected.
Could you run the ldd command on the following files and just let me know if any of them are also linked to libreadline.so.6 or if all are linked to libreadline.so.8
/bin/bash
/usr/bin/gawk
/usr/bin/sqlite3
/usr/bin/gpg
It would also be good if other people on the forum on CU167 can indicate if they have the same problem with bc being linked to libreadline.so.6
CU167 was released on 27th April so the old libreadline.so.6 library was still on your system when you tested your script. The library was removed as part of the CU167 update but you should have already been linked to the libreadline.so.8 library. That is what is unusual and at the moment I donāt understand it.
Thanks a lot Adolf for helping 
ldd /bin/bash | grep libreadline
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x000079d8d8a93000)
ldd /usr/bin/gawk | grep libreadline
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007f2c0b483000)
ldd /usr/bin/sqlite3 | grep libreadline
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x0000796a063f0000)
ldd /usr/bin/gpg | grep libreadline
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x000075cd1b531000)
So it looks like its just bc
Edit: forgot to mention:Im running on PC Engines ā apu1
Right.
So everything got its links updated on your system back in last year except for bc but on my system bc was also updated.
Donāt really understand that at the moment.
Will be good to hear if anyone else has the same problem.
Meanwhile I will try and have a think about it.
I will probably get bc to be shipped with CU168 or CU169 at the latest so the links should be updated.
Meanwhile your temporary fix will keep you working.
Maybe you could show the dates of the libreadline library files with the following command
ls -hal /usr/lib/libreadline*
I want to see how the date compares to mine, which is June 21 2021, although your libreadline.so.8 symlink will probably have a new date because of your renaming to libreadline.so.6 but the libreadline.so.8.1 library should still have the date from when it was originally updated.
I donāt believe that should give a problem but if other people on the forum using the apu1 can check the linked library on bc that would be good just to confirm.
I have access to a PC Engines ā apu4. It is linked to libreadline.so.8
ldd /usr/bin/bc
linux-vdso.so.1 (0x00007fffd4569000)
libfl.so.2 => /usr/lib/libfl.so.2 (0x000075c41f1c0000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x000075c41f166000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x000075c41f0ed000)
libc.so.6 => /lib/libc.so.6 (0x000075c41eee5000)
libm.so.6 => /lib/libm.so.6 (0x000075c41edfe000)
/lib64/ld-linux-x86-64.so.2 (0x000075c41f1cc000)
Funny. So it could be just my system?
Would it be a good fix to simply copy the bc from this system to mine?
Yes, that would be good so that you actually have the updated library being used on your system.
It might be, although I canāt think why that would happen.
On my APU1 System:
ldd /usr/bin/bc
linux-vdso.so.1 (0x00007ffdec5fd000)
libfl.so.2 => /usr/lib/libfl.so.2 (0x00007c47aea00000)
libreadline.so.6 => /usr/lib64/libreadline.so.6 (0x00007c47aed55000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007c47aecdc000)
libc.so.6 => /lib/libc.so.6 (0x00007c47ae7f8000)
libm.so.6 => /lib/libm.so.6 (0x00007c47ae711000)
/lib64/ld-linux-x86-64.so.2 (0x00007c47aedb6000)
ls -hal /usr/lib/libreadline*
-rwxr-xr-x 1 root root 351K May 6 09:16 /usr/lib/libreadline.so.6
lrwxrwxrwx 1 root root 18 Jun 18 2021 /usr/lib/libreadline.so.8 -> libreadline.so.8.1
-rwxr-xr-x 1 root root 351K Jun 18 2021 /usr/lib/libreadline.so.8.1
stat /usr/bin/bc
File: /usr/bin/bc
Size: 89104 Blocks: 176 IO Block: 4096 regular file
Device: 8,4 Inode: 486 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-05-06 10:07:00.549542882 +0200
Modify: 2019-02-24 15:17:54.000000000 +0100
Change: 2019-03-16 00:10:58.756669632 +0100
Birth: 2019-03-16 00:10:58.750002965 +0100
On other APU4 System:
ldd /usr/bin/bc
linux-vdso.so.1 (0x00007fff2a104000)
libfl.so.2 => /usr/lib/libfl.so.2 (0x00007cc097a62000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007cc097a08000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007cc09798f000)
libc.so.6 => /lib/libc.so.6 (0x00007cc097787000)
libm.so.6 => /lib/libm.so.6 (0x00007cc0976a0000)
/lib64/ld-linux-x86-64.so.2 (0x00007cc097a6e000)
ls -hal /usr/lib/libreadline*
lrwxrwxrwx 1 root root 18 Jun 21 2021 /usr/lib/libreadline.so.8 -> libreadline.so.8.1
-rwxr-xr-x 1 root root 351K Jun 22 2021 /usr/lib/libreadline.so.8.1
stat /usr/bin/bc
File: /usr/bin/bc
Size: 93200 Blocks: 184 IO Block: 4096 regular file
Device: 8,4 Inode: 533784 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-05-06 11:27:16.729349504 +0200
Modify: 2020-07-14 18:46:46.000000000 +0200
Change: 2020-08-26 10:50:50.243339020 +0200
Birth: 2020-08-26 10:50:50.233339020 +0200
OK, so I copied the bc command to my system - which of course did the trick. My system is very old and runs for many years ā¦ maybe over time something was missing during an update.
The date for the creation of the lib link on the apu1 is from Jun 18 2021. I am wondering if you might have installed an earlier testing version of CU157 on this machine and it only got part of the updates.
At least you are up to date now with the library and if no one else flags up a similar problem then we will have to presume that there was some hiccup on the apu1 machine around CU157 even if we donāt know specifically what.
Yes, I did not post because of my individual system. If Iām the only one thatās perfect.
Just wanted to check as I donāt know how many things in IPFire rely on bc.
Thanks again
That really could be the case. I was on ātestingā channel for a while back then.
Hi,
yes, unfortunately, that is one of the antics that come with testing Core Updates.
On some IPFire installations of mine, I switch to the testing channel as soon as a new update is available there, and when it is released as stable, I switch back to the stable channel as well. However, to ensure no quirks have been left, I then manually reinstall the latest Core Update (by decrementing the version number in /opt/pakfire/db/core/mine).
Rather hacky, but worked fine so far. 
Thanks, and best regards,
Peter MĆ¼ller