[olliej]

Do you mean have library B built with its own separate copy of the new version?

e.g. You have Library A using LibDependency-1.0.0 and Library B using a separately compiled LibDependency-2.0.0? Then have MyAwesomeApp linking LibA and LibB and just accept the binary+memory overhead of two copies (albeit different versions) of LibDependency?

[jasomill]

Probably, unless you need to share LibDependency data structures between 1.0.0 and 2.0.0, in which case, it depends on the implementation of LibDependency.

Rather than trying to do this at the language level with namespaces or whatever, it's probably easier to compile and link each version of the problem dependency into a separate library (static or dynamic), then to make sure each of your own libraries and executables only directly links to one version of the problem library.

This way, you don't have to rename or namespace anything, because conflicting names will only be exposed externally if you're linking to the problem library dynamically, in which case you should be able to arrange for the names to be qualified by the identity of the correct version of the problem library at dynamic load time (how to ensure this is platform-specific).

[jamesfinlayson]

I've never tried it but I read that a use for namespaces was talking a library and wrapping all the #include statements in namespace library {} or whatever to avoid one stepping on another. Depending on how the library is written (and if it's all in source form rather than .lib files) I guess it should work?

[olliej]

The problem comes from what happens when you're trying to use LibDependency from your own code, say for example you're have something like:

    LibDependency.h:
      typedef struct SomeOpaqueLibDependencyType * SomeOpaqueLibDependencyTypeRef;
      SomeOpaqueLibDependencyTypeRef MakeTheThing();
      void UseTheThing(SomeOpaqueLibDependencyTypeRef);

   
    LibraryA:
      ...
      SomeOpaqueLibDependencyTypeRef getSomething();

    LibraryB:
      ...
      void doSomething(SomeOpaqueLibDependencyTypeRef);

    MyAwesomeApp:
      LibraryB.doSomething(LibraryA.getSomething()) // pseudocode

The problem is the because LibraryA and LibraryB have distinct copies of LibDependency, the source/api compatible type you're using may have an incompatible internal structure.

As a library author there are things you can do for ABI compatibility, but they all basically boil down to providing a bunch of non-opaque API types that have some kind of versioning (it's either an explicit version number, or it's a slightly implicit size field which IIRC is the MS standard). You also have opaque types where the exposure of details is more more restricted, generally either just an opaque pointer, or maybe a pointer to a type that has a vtable (either an automatic one or a manually constructed one). In general use of the non-opaque portions of the API are fairly restricted because they have ABI implications, so a user of a library will communicate by providing those non opaque data to the library, but the library will provide largely opaque results with an ABI stable API that can be used to ask questions of an otherwise opaque type.

This works in general, and it means you don't have to rebuild everything from scratch any time you update anything. It breaks down however when you have different versions of the same library in the same process. The problem is that while you see a single opaque type, it's not opaque to the library itself so while an opaque type from two different versions of a library may look the same to you, the implementation may differ between the two versions. Take a hypothetical:

    LibDependency.h:

      typedef struct OpaqueArray *ArrayRef;
      struct ArrayCallbacks {
        int version;
        size_t elementSize;
        void (*destroyElement)(void *);
        void (*copyElement)(void *, const void*);
      };
      ArrayRef ArrayCreate(const ArrayCallbacks*, size_t);
      void ArraySet(ArrayRef, size_t, void*);
      void *ArrayGet(ArrayRef, size_t);

which is a kind of generic vaguely ABI stable looking thing (I'm in a comment box, assume real code would have more thought/have fewer errors), but lets imagine the a "plausible" v1.0

    LibDependency-1.0.c:
      struct InternalArrayCallbacks {
        void (*destroyElement)(void *);
        void (*copyElement)(void *, const void*);
      };
      struct OpaqueArray {
        InternalArrayCallbacks callbacks;
        size_t elementSize;
        char buffer[];
      }
      ArrayRef ArrayCreate(const ArrayCallbacks* callbacks, size_t size) {
        size_t allocationSize = sizeof(OpaqueArray) + size * callbacks->elementSize;
        OpaqueArray *result = (OpaqueArray *)malloc(allocationSize);
        /* initialize result, copy appropriate callbacks, etc */
        return result;
      }
      void ArraySet(ArrayRef array, size_t idx, void* value) {
        array->callbacks.copyElement(array->buffer + idx * array->elementSize, value);
      }

etc.

Now v1.1 says "oh maybe we should bounds check":

    LibDependency-1.1.c:
      ...
      struct OpaqueArray {
        InternalArrayCallbacks callbacks;
        size_t elementSize;
        size_t maxSize;
        char buffer[];
      }
      ...
      void ArraySet(ArrayRef array, size_t idx, void* value) {
        if (idx >= array->maxSize) abort();
        array->callbacks.copyElement(array->buffer + idx * array->elementSize, value);
      }

There's been no source change, no feature change, and from a library/OS implementors PoV no ABI change, but if I had an ArrayRef from the 1.0 implementation and passed it somewhere that would be using the 1.1 implementation, or vice versa, the result would be sadness.

As a library implementor there's a lot you have to do and/or think about to ensure ABI stability, and it is manageable, but more or less all of the techniques break down when the scenario is "multiple versions of the same library inside a single process".