[racket] policy on providing version for ffi-lib

On 05/02/2011 07:20 PM, Danny Yoo wrote:
> I notice that Sqlite's library is usually installed as
> 'libsqlite3.so.0' on a user's system, but the sqlite PLaneT package:
...
> appears to assume that the library is named libsqlite3.so.

Some of the major linux distributions (e.g. RedHat/Centos) have been 
moving this way in recent years.

On my more traditional linux system,
/usr/lib64/libsqlite3.so -> libsqlite3.so.0.8.6*
/usr/lib64/libsqlite3.so.0 -> libsqlite3.so.0.8.6*
/usr/lib64/libsqlite3.so.0.8.6*

It has been common procedure for C/C++ programs to link to "-lsqlite3" 
for decades now.  Unfortunately, this causes the executable to 
reference "libsqlite3.so", and that makes it harder to maintain 
multiple versions of the library on a system, thus making safe 
upgrades harder.  However, it is such a common practice that all 
"devel" RPMs I have seen restore the missing symlinks.

The stricter soname versioning has been causing link issues for all C 
and FFI systems of late.  Unfortunately, even today many major 
libraries don't follow the old soname conventions (read: no standard) 
and thus you sometimes really need to use the fully versioned name 
(the whole 0.8.6).  (Why isn't it libsqlite.so.3.8.6??)  In fact, the 
full name is the only one you will find on some systems these days.

It might be preferable to have (define sqlite (ffi-lib "libsqlite3")) 
implicitly perform a wildcard search, though I don't know how that 
could be effected properly.  Look at the ld.so or dlopen manpages to 
see how hairy it gets.

- Daniel