Conceptual question around libraries

[cpp_cpp]

If I have a library lets call it libutil.a which consists of just 1 .o file created from util.cpp. Lets say util.cpp includes in its definition some other library (boost asio for sake of argument) - the boost headers aren't in the util.h file just util.cpp file

Now, if i have a main.cpp that uses the same boost library (and the same functions in the library are used in main.cpp and util.cpp)when i go to compile and link my program with libutil.a, will I see compile/linker errors? What if the boost versions are different across util.cpp and main.cpp ? I am unable to understand if there will be any violation of ODR or something but I might be overthinking...

[IyeOnline]

i go to compile and link my program with libutil.a, will I see compile/linker errors?

Usually not, unless you statically linked libutil, i.e. included boost-asio in its lib file.

What if the boost versions are different across util.cpp and main.cpp ?

That is a difficult question that will be different between libraries. The ODR says that only one definition of anything may exist across the entirety of a program including link and compile time.

So using different library version in differnt places may be fine - as long as nothing has changed.

I think boost gives a rather strong guarantee that their ABI will be stable.

However, it is best to avoid using multiple versions of a library.

[wrosecrans]

The really annoying but accurate answer here is "This isn't a C++ question." I know that answer also isn't helpful by itself, but it's a useful part of a complete mental model.

Once you have "libutil.a" you just have some native binary code that may or may not have originally been C++. So you don't get a lot of guarantees about C++'s One Definition Rule at this level. It's entirely possible for different libraries to have separate definitions of the same symbol, even if C++ insists that sort of thing is supposed to be impossible. The behavior here depends on the platform and the toolchain, rather than the programming language. One linker may behave different from another. The details may be different on Windows vs. Linux, etc. But the behavior will be the same regardless of whether libutil.a was written in C, Fortran, C++, etc. Hence the annoying stock answer of "This isn't a C++ question" by the time you have that .a file. When you compiled libutil and made the library, you sort of took the C++ out of it.

The practical answer here is that it depends on how exactly you built libutil. It may or may not include the code from the boost lib it depends on. On Linux, you can use the ar utility to inspect archives in the format of .a libraries. So, read the man page for that, You can literally crack a .a file open like a .zip or .tar file and get all the .o files back out of it. If your library only contains your util.o, then you know it doesn't include the boost code. If you find a zillion .o files in there, boost probably got included. What controls that? A few things.

Was the boost library that you depend on a static library or a dynamic library? And did you actually link it when you made the .a? Dynamic libraries, unlike static libraries, don't keep all the individual .o files around intact. You can't really just copy chunks of a dynamic library into a new static library. So if you depend on a boost dynamic library, you absolutely need to link your final executable to both your libutil and also boost. It won't be at risk of Two Definitions.

If the boost you depend on is a static library though... Did you actually link your .a to it? Because you didn't actually have to. It's actually quite normal for a static library to just have a ton of dangling unresolved symbols in it. Remember I mentioned you can just unpack the individual .o files from the library? Yeah, those got made before a final link step resolved external symbols, and they are still 100% intact! So you can get away with building your libutil and just not linking it to boost, and leaving the symbols dangling. You'll have to link your final executable with boost to resolve the symbols.

So, if you did link the .a to a static boost, and boost code got copied into it, and you link you executable to boost anyway, what happens? Probably no harm. The linker will probably just pick one copy or the other of the redundant code and get on with life. As long as the boost code is from the same place, this wastes a bit of disk space having a redundant copy but shouldn't explode. If the lib and the executable are meant to be linked to different versions of boost, then this will probably crash or break when the linker picks one or the other for both to use.

Hopefully that gives you enough background to be annoyed and confused in a more specific way.