1.6, Guile's shared libraries, Debian packaging, and versioning.

[Han-Wen]

address@hidden writes:
> The questions involved are ones like, "What are the actual
> interdependencies between our scheme modules and our shared libs?"
> "When is it OK to break API compatibility?"  "Are shared libraries

I don't where the special problem is. All extension languages have to
deal with this issue. If you want to be on the safe side, then GUILE
should install every non-versioned run-time file (i.e. .scm or
unversioned .so files), in a separate subdirectory bearing the version
number.

for example, for python

        blauw:/tmp$ ls -ld /usr/lib/python*
        drwxr-xr-x    8 root     root        12288 May 14 22:03 
/usr/lib/python1.5
        drwxr-xr-x    3 root     root         4096 Oct 30  2001 
/usr/lib/python2.0
        drwxr-xr-x    2 root     root        12288 May 14 22:20 
/usr/lib/python2.1
        drwxr-xr-x   11 root     root        12288 May 14 22:20 
/usr/lib/python2.2

[..]
> If that's right, then there might be a lot less reason not to just
> have something less complex.
> 
>   /usr/lib/libguile.so.12.0.1
>   /usr/lib/guile/12/libsrfi-4.so
>   /usr/lib/guile/12/libpg-interface.so
>   /usr/lib/guile/12/libsomething-else.so
> 
> which makes the issue clear in the filesystem.  At least this was the

Yes, this is the way to go, except that I would use the GUILE version
number, as it is more recognizable, i.e.


    /usr/lib/guile-1.6/libguile.so.12
    /usr/lib/guile-1.6/libsrfi-4.so
    /usr/lib/guile-1.6/scm/frob.scm

etc. guile-config can return the proper -L flags for linking. 

-- 

Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen