l...@gnu.org (Ludovic Courtès) writes: > Hi Andreas, > > Andreas Rottmann <a.rottm...@gmx.at> writes: > >> Another related issue that has come up in IRC is versioning: If I >> understand correctly, it is currently impossible to specify the version >> of the shared object to be used (as one cannot even pass a full filename >> to `dynamic-link'). This has two (IMHO) unacceptable implications: >> >> (1) On GNU/Linux, the .so symlink has to be installed for the FFI-using >> code to work. At least on Debian, this means that the -dev package >> (which contains that symlink) has to be installed. In turn, any >> Guile application or library that would be packaged for Debian would >> have to depend on the -dev package. This is Wrong(tm). There is >> nothing inherent in a language binding for a given C library that >> would require the presence of e.g. headers and the static library >> (or library documentation, which is also often provided in the -dev >> package) *at runtime*. > > I understand and I agree that this is a real problem, but this looks to > me like a Debian-centric discussion. I think ltdl’s file lookup rules > should not be changed just to abide by the packaging rules of a distro. > This is not just Debian (and derivatives), I just used Debian as an example sice it is what I know best. Splitting out files needed only for development is a common practice on at least Fedora[0], and OpenSuSE[1], and I suspect most distributions that ship binary packages.
[0] http://fedoraproject.org/wiki/PackagingGuidelines#Devel_Packages [1] http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Examples >> Currently, guile uses lt_dlopenext(), which does not seem to provide a >> way to specify ABI version information at all. I'd propose extending >> `dynamic-link' to allow for an optional second argument, similiar to >> Racket's `ffi-lib'[0]. If that argument is provided, Guile would use >> lt_dlopen() instead of lt_dlopenext(), passing it a shared library name >> containing the specified ABI information. Of course the mangling of the >> library name and ABI version would depend on the platform, but on >> GNU/Linux, it would work something like this: >> >> (dynamic-link "libSDL-1.2" '("0")) ;; calls: lt_dlopen("libSDL-1.2.so.0") >> >> [0] >> http://docs.racket-lang.org/foreign/Loading_Foreign_Libraries.html?q=ffi-lib#(def._((lib._ffi/unsafe..rkt)._ffi-lib)) > > Can you show actual uses of this of the VERSION argument? > > As I mentioned in another message, the SONAME and file name is a > system-dependent thing. So my impression is that it would be impossible > to use it portably. > Yep, you are right (unfortunatly ;-)). However, I think most "interesting" libraries today use libtool, which uses a portable, common-denominator mechanism to supply version information (see "7.2 Libtool's versioning system" in the libtool manual), centered around the concept of an interface number represented as an integer. So I guess it might be possible to specify this libtool interface number and extend libltdl to map this to the right system-specific magic number/name. > IMO the Right Thing to do on GNU systems (and Solaris, at least) would > be to allow ‘dynamic-func’ to use symbol versioning [0]. That would be > finer-grain and would not rely on SONAME magic numbers. > Having symbol versioning support is certainly a good thing to have, but it requires upstream supporting it -- not all libraries provide versioned symbols. Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
