Bc shell command - missing libreadline.so.6

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

2 Likes
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.

2 Likes

Thanks a lot Adolf for helping :heart:

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.

1 Like

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.

1 Like

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.

3 Likes

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.

1 Like

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. :slight_smile:

Thanks, and best regards,
Peter Müller

4 Likes