[cffi-devel] librt soname

[Andy Hefner]

On 7/3/09, Luis Oliveira <luismbo at gmail.com> wrote:
> It used to be librt.so.1, but it was changed to librt.so, not sure
>  why. Is there any system where "librt.so.1" doesn't work but
>  "/lib/librt.so.1" would?

Changing /usr/lib to /lib was random flailing around on my part. I'm
not sure where it's supposed to live.  On the older kubuntu VM I've
been doing some tests in, it has:

   /lib/librt-2.6.1.so
   /lib/librt.so.1 -> /lib/librt-2.6.1.so
   /usr/lib/librt.so -> /lib/librt.so.1

For reasons unknown to me, despite the /usr/lib/librt.so existing, it
couldn't find librt until I changed it to librt.so.1.

As for distributing libraries with the executable, so far I haven't
needed to (recall the strange efforts I took to avoid distributing the
osicat wrapper.so), but I've just been thinking about out how to do it
in order to distribute a version of libmpg123 with known compilation
options. I was going to give it name (like libshuffletron-mpg123) and
copy it into /usr/local/lib where it will be found automatically, but
the trouble then is to also make the program runnable after untarring
it without doing a 'make install'. I hadn't thought of
cffi:*foreign-library-directories* but that sounds useful.

So far as CFFI is concerned, its problems at present are that it seems
to forget entirely the existence of libraries loaded directly by
pathname (such as wrapper.so), and these are precisely the ones that
cause trouble with deployment.