On 2015-01-20 11:08:46, Rich Shepard <[email protected]> wrote: > Somehow, libncurses is present in two copies, with different dates and > file sizes. This may be the reason I'm having problems using unixODBC so I > want to clean this up. Did not find the file containing libncurses; it may > well be in one of the base Slackware files, such as aaa_libs. >
Disclaimer: I use OpenBSD, which sometimes does things differently than Linux does, but they're both *nix based POSIX operating systems. I'm curious if these are causing a problem you're trying to solve. If not, I'd recommend leaving them in-place since they appear to be symlinks and are not taking up much disk space. > Here are the two directories' contents: > > ll /lib/libncurses* > lrwxrwxrwx 1 root root 17 Mar 9 2014 /lib/libncurses.so.5 -> > libncurses.so.5.9* > -rwxr-xr-x 1 root root 313416 May 7 2013 /lib/libncurses.so.5.9* > lrwxrwxrwx 1 root root 18 Mar 9 2014 /lib/libncursesw.so.5 -> > - libncursesw.so.5.9* > -rwxr-xr-x 1 root root 395048 May 7 2013 /lib/libncursesw.so.5.9* > > Need to remove the 2013 files while leaving the 2014 files in place. > The 2013 files are the actual library. The 2014 files are symlinks that are only 17 and 18 bytes in size and are linking the name without the trailing ".9" to one with it. This is presumably so that an application that wants to have libcurses with a "5" as the major version, but doesn't care what the minor version is, can simply request "libcurses.so.5" and get whatever it is linked to. Removing this link may break applications. > and > > ll /usr/lib/libncurses* > -rw-r--r-- 1 root root 414822 May 7 2013 libncurses++.a > -rw-r--r-- 1 root root 416350 May 7 2013 libncurses++w.a > -rw-r--r-- 1 root root 488966 May 7 2013 libncurses.a > lrwxrwxrwx 1 root root 20 Mar 9 2014 libncurses.so -> > - /lib/libncurses.so.5* > lrwxrwxrwx 1 root root 12 Nov 7 2010 libncurses.so.5 -> libcurses.so* > -rw-r--r-- 1 root root 592644 May 7 2013 libncursesw.a > lrwxrwxrwx 1 root root 21 Mar 9 2014 libncursesw.so -> > - /lib/libncursesw.so.5* > lrwxrwxrwx 1 root root 13 Nov 7 2010 libncursesw.so.5 -> > libcursesw.so* > > Need to remove the 2010 and 2013 copies while leaving the 2014 copies in > place. > And in here it's taking it a step further, linking a versioned library with a major version of "5" to an unversioned library. This is being done presumably so that an application that just wants "libncurses" and doesn't care which version it gets, to ask for "libncurses" and have the link point to the specific version. Since these links are very small, only a couple dozen bytes each, and are providing an important compatibility layer to applications that may not be specifically asking for "libcurses.so.5.9" and are either asking for "libcurses.so.5" or "libcurses.so" The version of the library with a 'w' in the name supports "wide" characters, which should allow support for Cyrillic, Greek, and Asian writing systems to be used, though since it's probably using unicode, it may also be used to allow things like umlauts and cedillas to be used in the Latin alphabet. It's probably worth keeping around as well. > Don't know if the solution is distribution-specific or -agnostic. > Repeating the above disclaimer: I use OpenBSD, not Linux, but these should be fairly standardized across platforms. If you do not have any specific problem you're trying to solve by deleting the older files, you may (probably are very likely to) create one if applications that don't care which version of libncurses they get end up no longer functioning when the old symlinks are removed. That being the case, I would advise simply letting things be as they are, since it looks like they were deliberately set up to function this way, with the multiple links pointing to differently named files. -- Bryan _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
