On 7/3/09, Luis Oliveira luismbo@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.