Are Nested Static Library dependencies possible?

Question

I am working in QT .

1. Can a static library depend on another static library?(Static Lib is made by linking another static lib)
2. If yes, is it possible that after linking to lib2, the generated lib(lib1) would not contain all the codes of lib2?

In my Qt Project I am using a static library, which depends on multiple libraries. I had to add all the libraries (with all their headers in my project), although I need only one lib (and one .h of that class) in my code.

Please explain the scenario.

Answer 1

My quick two bits on this: 10 (sorry terrible joke).

To expand slightly, here goes:

1- A static library can depend on another static library, nothing or even a dynamic library: in the first two instances all the code for the new static library would be incorporated in the new SLL (Static Link Library), however, the 3rd option, depending on evironment could lead to the SLL having one of the following outcomes,

• it would contain static versions of the code required by it gathered from the DLL (Dynamic Link Library)
• or, much more horribly, you would have a static library that when included in a project would cause the requirement of shipping with a DLL , breaking the whole point of static linking.

So in short yep, you can link a static library to a static library

2- if lib1 and lib2 are both static, and lib1 has been linked with lib2, then all the functionality of lib2 would be available within lib1 without the need to include lib2 as lib2 would be statically linked within lib1 (think russian dolls, with lib2 being the smaller).

In the scenario you describe there must be discrete functionality available in each of the files you are having to include, which is not statically linked, hence the need for multiple files, otherwise you would have a single file to include and you would be fine.

Take the following: One .h file with references to 6 statically linked libraries: you would need to include 7 files in your project to get full functionality

One SLL which was created from said .h File would require only the new SLL to be included for linking at compilation:

Hope this helps and that I have understood what you were asking.

Answer 2

When you declare something you just promise that during linking it will be available and uniquely identified. Static libs are nothing more than containers for definitions in a format which is outside the standard. So, this has the following implications:

1 ) I don't quite get what you're asking here, but one static library can very much depend on another static library. Either you promise that the definitions of that library be available during the final linking stage of your executable ( by providing it as link dependency ). Or you "merge" it during linking of the static lib.

2 ) The answer to this then becomes that the only thing you need to do is simply to not link in lib2 during linking of lib1.

Overall the best approach in my experience is to only merge libs which are private, the reason being that otherwise clients will run into multiply defined symbols violations when other parts of their project shares dependencies with you.

Answer 3

In binutils 2.36, ar added --record-libdeps to record dependencies in an archive. GNU ld reads the dependencies from the __.LIBDEP member. https://sourceware.org/pipermail/binutils/2021-January/115071.html

However, I am not sold on this feature.

---

Clang and ld.lld support a more fine-grained scheme. #pragma comment(lib, "libabc") causes Clang to generate a section .deplibs. When linked by ld.lld, ld.lld searches for the referenced file (it will try -L as well so both libabc.a and abc work)).