Support for ABI versioning of C libraries

[uzytkownik]

Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.

Also it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.

More informations:  http://bugs.gentoo.org/show_bug.cgi?id=290974  http://bugs.gentoo.org/show_bug.cgi?id=311361

[simonmar]

In GHC we don't currently support the kind of ABI versioning you get in C libraries where you can have a .so that supports multiple ABI versions. Instead we encode the version directly in the filename of the .so, as in libHSbase-ghc6.12.3.so. Even this is quite suspect as there is no guarantee that a given libHSbase-ghc6.12.3.so has the same ABI as another libHSbase-ghc6.12.3.so. The problem is that GHC is not capable of producing a library that has a consistent, predictable, ABI. I'd like to fix this someday, but it's not a simple task.

For linker scripts see #2615.

[uzytkownik]

Replying to simonmar:

In GHC we don't currently support the kind of ABI versioning you get in C libraries where you can have a .so that supports multiple ABI versions. Instead we encode the version directly in the filename of the .so, as in libHSbase-ghc6.12.3.so. Even this is quite suspect as there is no guarantee that a given libHSbase-ghc6.12.3.so has the same ABI as another libHSbase-ghc6.12.3.so. The problem is that GHC is not capable of producing a library that has a consistent, predictable, ABI. I'd like to fix this someday, but it's not a simple task.

I Meant ABI versioning of C/Fortran/... library - non Haskell one.

[simonmar]

Could you say what kind of support you want?

[uzytkownik]

Currently it is not possible to specify in .cabal file the version of library - only it's name. However as ABI changes I want to link with libsomething.so.x. In such way tools like revdep-rebuild etc. will work.

[simonmar]

Ok, after talking to Duncan Coutts I think I understand what is needed here.

• when registering a package we should somehow figure out which version of the .so for each dependency it is linking to, and note that in the InstalledPackageInfo for the package. Perhaps we just note the major version, not the minor. Figuring out what the .so version is could be hard - we might have to compile a dummy program and inspect it with ldd.

• when linking a program against the package, we will have to resolve the library to an absolute pathname (e.g. /path/to/libfoo.so.2.3) and pass that to the linker.

We don't think that you need to specify ABI versions in the .cabal file; it's something that should be fixed when the package is built and stored with the registered package.

[draconx]

Replying to simonmar:

Figuring out what the .so version is could be hard - we might have to compile a dummy program and inspect it with ldd.

Surely it's just a matter of reading the DT_SONAME field from the shared object?

[simonmar]

Replying to draconx:

Surely it's just a matter of reading the DT_SONAME field from the shared object?

The difficulty is finding the shared object in the first place, i.e. resolving a library name to .so file, which is the linker's job not ours.