On 20 March 2017 at 18:13, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 20 March 2017 at 16:12, David Bernier wrote: >> I have installed the PARI/gp calculator software, which I compiled >> >> with the readline library included to facilitate editing of lines at the >> console. >> >> >> This morning I did an update of CentOS 6.8 x86_64, which is a "clone" >> >> of Red Hat Enterprise Linux, minus the branding. >> >> >> For that, I did: >> >> # yum update >> >> >> Now, gp complains about missing symbols. >> >> The ldd command with options -d and -r gives the following: >> >> >> $ ldd -d -r /usr/local/lib/libreadline.so.6 [ENTER ] >> >> linux-vdso.so.1 => (0x00007ffd4207e000) >> libc.so.6 => /lib64/libc.so.6 (0x00007f5aae028000) >> /lib64/ld-linux-x86-64.so.2 (0x0000003afc600000) >> undefined symbol: PC (/usr/local/lib/libreadline.so.6) >> undefined symbol: UP (/usr/local/lib/libreadline.so.6) >> undefined symbol: BC (/usr/local/lib/libreadline.so.6) >> undefined symbol: tgetflag (/usr/local/lib/libreadline.so.6) >> undefined symbol: tgetent (/usr/local/lib/libreadline.so.6) >> undefined symbol: tputs (/usr/local/lib/libreadline.so.6) >> undefined symbol: tgoto (/usr/local/lib/libreadline.so.6) >> undefined symbol: tgetnum (/usr/local/lib/libreadline.so.6) >> undefined symbol: tgetstr (/usr/local/lib/libreadline.so.6) >> >> >> and then when I looked at the modification date I get this: >> >> $ ls -l /usr/local/lib/libreadline.so.6 [ENTER ] >> >> lrwxrwxrwx. 1 root root 18 Mar 20 10:54 /usr/local/lib/libreadline.so.6 -> >> libreadline.so.6.3 >> >> This means a change was made within the last 1 to 2 hours. >> >> My fix for the gp readline problem is to do >> >> a symbolic link with: >> >> /lib64/libreadline.so.6 which has a symlink to /lib64/libreadline.so.6.0 : >> >> $ ls -l /lib64/libreadline.so.6 >> lrwxrwxrwx. 1 root root 18 Feb 4 02:07 /lib64/libreadline.so.6 -> >> libreadline.so.6.0 >> >> $ ls -l /lib64/libreadline.so.6.0 >> -rwxr-xr-x. 1 root root 272008 Jun 22 2012 /lib64/libreadline.so.6.0 >> >> === >> >> If I run the same `ldd' command on the old library >> >> /lib64/libreadline.so.6.0 >> >> I get the following: >> >> $ ldd -d -r /lib64/libreadline.so.6.0 [ ENTER ] >> >> linux-vdso.so.1 => (0x00007fffe08e3000) >> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003b0fa00000) >> libc.so.6 => /lib64/libc.so.6 (0x0000003afce00000) >> /lib64/ld-linux-x86-64.so.2 (0x0000003afc600000) >> >> It doesn't report any undefined symbols, which is why I >> >> symlink to it so that `gp' will work. >> >> I'd like to know why the Packagers continue to make >> >> symlinks to: /usr/local/lib/libreadline.so.6.3 >> >> which here using ldd -d -r shows up as having undefined symbols, >> >> or in the alternative (supposing I'm creating problems with >> >> my workaround for `gp' and librealine), how >> >> to compile or re-compile the PARI/gp source code so that >> >> it will not interfere with what the Packagers have fixed and >> >> got running fine. > > This has nothing to do with GCC. Presumably you linked your program with -lreadline which will have looked for a file called libreadline.so If that is a symlink to libreadline.so.6.0 then that's what your software will link to and depend on. If you install the readline-devel package it should install a symlink called libreadline.so that points to the libreadline.so.6 library version installed by the system packagers.
