4

We need to integrate a closed-source C library into our project. The other party can compile the library in any mode we need, but we support a lot of different Windows and Linux compilers.

I know a DLL will be compatible with all major Windows compilers, so we could only use one library for Windows. But I’m not familiar with Linux dynamic libraries (.so). Are these compatible across all Linux environments in a similar way?

Thanks

Neil Kirk
  • 21,327
  • 9
  • 53
  • 91
  • A DLL *won't* be compatible across compilers on Windows if it contains any C++ exports - That's only true if it contains exports in a compatible format such as `extern "C"`. – RobH Mar 14 '14 at 10:40
  • It is pure C library. (Updated tag, although our project is C++) – Neil Kirk Mar 14 '14 at 10:41
  • "I know a DLL will be compatible with all major Windows compilers, so we could only use one library for Windows." - try it first. I know that - "Object files and static libraries created with different compilers, or even with significantly different releases of the same compiler, often cannot be linked together. (source http://www.mingw.org/wiki/MixingCompilers) – SChepurin Mar 14 '14 at 11:20
  • @SChepurin "Dll's are slightly different. Sometimes you can link a DLL built with one compiler to an application compiled with another." We can do this. – Neil Kirk Mar 14 '14 at 11:21
  • If you ask your vendor to build against the *oldest reasonable* version of glibc you should be safe. Otherwise the library may fail to work in older Linux environment. – n. m. could be an AI Mar 14 '14 at 11:47
  • 2
    Out of experience, it takes a quite astounding amount of effort to create shared libraries and binaries that works on different distros and versions there of. You normally end up with a shared library that requires runtime libraries/versions/symbols that are incompatible across distros. If you only use libc, and create the shared library on a sufficiently old distro/glibc version, you might have a chance though. – nos Mar 14 '14 at 11:47
  • The word you are looking for is ABI. Do all windows compilers have the same ABI? I doubt it. Do all Linux compilers have the same ABI? Certainly not. What you need is to check for ABI-compatibility between the compilers (and their versions!) you plan on supporting. – Shahbaz Mar 14 '14 at 11:56

2 Answers2

2

You may have some issues w.r.t. the version of the GNU libc against which that shared library libotherparty.so has been linked (and compiled).

You certainly need to know the version of the libc, and you might require that party to ship several variants of the binary library.

I would strongly suggest to read Drepper's paper: How To Write Shared Libraries. See also this question and Levine's linker & loader book.

If it is C code, the compiler does not matter much. What matters more is the ABI. Learn also about symbol versioning.

Be prepared to have some trouble.

You'll learn by experience that free software is preferable.

Community
  • 1
  • 1
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Hi thanks for your answer. Linux noob here. Re: first sentence. I can get them to link against any GNU libc necessary. What should I tell them for maximum compatibility? Re: second sentence. What variants do I need? I just want 32-bit .so and 64-bit .so libraries I can use on any Linux distro with gcc. Thank you. – Neil Kirk Mar 24 '14 at 18:39
1

Library versions should be specified for shared objects if the function interfaces are expected to change (C++ public/protected class definitions), more or fewer functions are included in the library, the function prototype changes (return data type (int, const int, ...) or argument list changes) or data type changes (object definitions: class data members, inheritance, virtual functions, ...).

The library version can be specified when the shared object library is created. If the library is expected to be updated, then a library version should be specified. This is especially important for shared object libraries which are dynamically linked. This also avoids the Microsoft "DLL hell" problem of conflicting libraries where a system upgrade which changes a standard library breaks an older application expecting an older version of the the shared object function.

Versioning occurs with the GNU C/C++ libraries as well. This often make binaries compiled with one version of the GNU tools incompatible with binaries compiled with other versions unless those versions also reside on the system. Multiple versions of the same library can reside on the same system due to versioning. The version of the library is included in the symbol name so the linker knows which version to link with.

One can look at the symbol version used: nm csub1.o

00000000 T ctest1

No version is specified in object code by default.

Look ld and object file layout

There is one GNU C/C++ compiler flag that explicitly deals with symbol versioning. Specify the version script to use at compile time with the flag: --version-script=your-version-script-file

Note: This is only useful when creating shared libraries. It is assumed that the programmer knows which libraries to link with when static linking. Runtime linking allows opportunity for library incompatibility.

Also look here regarding ABI compatibility

Jayesh Bhoi
  • 24,694
  • 15
  • 58
  • 73