Menu
I have a problem that bothers me. I think I encountered it in the past, but I can't find information about similar issues on the internet.
Assume that I have:
If between 'common' v1.3 and v1.2 were added new components only, everything should be fine, right?
If 'common' v1.3 changed the API used by 'extra-common', probably I would get a missing symbol issue while linking 'extra-common' with the rest of app.
If 'common' v1.3 keeps the same API as v1.2, but changes some internals, is it possible to have some crashes in runtime (caused by change in size of objects or maybe by changes of vtable, etc)?
Could you send me some terms that I can google, some scenarios what could cause a runtime crash or some links to articles? Is such a term like "diamond problem in libraries dependencies"?
I would be grateful for anything.
972
A diamond dependency conflict is a scenario where two or more libraries in a dependency tree consume a common library using versioned references, and none of the common library versions in those references contain all of the features that the consumers expect.
So what is a Static library?? This is the most straight forward way of using a library as the final result is a simple executable with no dependencies.
In the C programming language, a static library is a compiled object file containing all symbols required by the main program to operate (functions, variables etc.) as opposed to having to pull in separate entities. Static libraries aren't loaded by the compiler at run-time; only the executable file need be loaded.
Static libraries are either merged with other static libraries and object files during building/linking to form a single executable or loaded at run-time into the address space of their corresponding executable at a static memory offset determined at compile-time/link-time.
The (possible) problem you're describing here isn't that you have a diamond structure in your dependencies, it's that you're using a library (extra-common) that depends on libcommon1.2a, but you're linking against libcommon1.3a instead. It sounds like you already understand why that might not be safe.
I think the term you're looking for is ABI: application binary interface. It's the elements of compiled code that have to match up between modules that are linked together, such as calling conventions and structure layouts. ABI is analogous to API, but it pertains to compatibility of compiled code instead of source code. The two are independent of each other: you can break API without breaking ABI (e.g. by renaming a field in a structure), and you can break ABI without breaking API (e.g. by changing the size of a data type, or rearranging the fields in a structure).
If libcommon1.3a is not ABI-compatible with libcommon1.2a, you can't safely use your extra-common library with it. You'll need to recompile the extra-common component using libcommon1.3a headers. (If 1.3a is not API-compatible either, you'll probably have to make changes in extra-common too.)
128
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
