What's the down side to linking to libraries you don't use

Lately I've been using GUI libraries. I always start by using CMake to write my makefile. Since I'm lazy I tend to use the same CMakeLists.txt every time and all I do is change the sources. This CMakeLists.txt list all the possible libraries that I might possibly use to write a GUI, but I'm not using them all.

I always assumed that if they're not used there is no cost, but I don't know that to be true.

And in the same vein what's the cost of including headers in your source code that you don't use?
Last edited on
Interesting question. Hadn't really thought of it like that. If someone wants to do the following in VSC++ or with other libs to compare that would be cool. Using gcc/g++ and SDL2 on Linux this what I got;
By taking the following code:
#include <iostream>

using namespace std;
int main()
        cout << "hello\n";

I ran these tests;
noLibs: default, no linking, no headers
SDLLinked: Linked to the SDL2 library, but did not #include <SDL2.h> in the code
SDLHeaderLinked: Added a single #include to the SDL2 library and also linked in make
SDLHeaderLinkedInitialized: did all the above and called SDL_INIT(SDL_INIT_EVERYTHING);

19936(bytes) Nov 7 19:19 noLibs
19936(bytes) Nov 7 19:19 SDLLinked
19936(bytes) Nov 7 19:19 SDLHeaderLinked
19976(bytes) Nov 7 19:19 SDLHeaderLinkedInitialized
// same as above 3 but with -O3 turned on:
19832(bytes) Nov 7 19:19 noLibsOptimized
19832(bytes) Nov 7 19:19 SDLLinkedOptimized
19840(bytes) Nov 7 19:19 SDLHeaderLinkedOptimized
19880(bytes) Nov 7 19:19 SDLHeaderLinkedInitializedOptimized

So adding linkage and including the library headers has pretty much no effect in g++ (though oddly it did by 8 bytes with Optimization turned on). It took actually calling a function from the library before it changed the size of the output file.

I'll note that removing the #include <iostream> does change the size of the output file by some 700 bytes or so. If C++ native libs follow different rules, maybe other external libs might as well? SDL is pure C, so maybe libs containing C++ template classes might make a difference (that could modify the vtable, though I don't think it would until said template class/function was actually used. I can't think of any libs that use template classes/functions to test this on...)

Upside: you don't have to type several repetitive lines of code every time you start a new project.

Downsides might include people thinking they have to learn those included libs in order to work on your code, general confusion, and added lines of code for no reason. If the linkage is made as well then you have to work out shared dll/so files or just remember to fix the Makelist before distributing. In general the downsides are only relevant if you intend to share your programs with other people...
Last edited on
Thank you for your reply it helped me. I tried a version of your test, this is my results:
-rwxr-xr-x  1 wilson wilson  22704 Nov  8 07:42 hello_linked_wxwidgets_lib_but_not_used
-rwxr-xr-x  1 wilson wilson   8680 Nov  8 07:44 hello_not_linked_wxwidgets

I ran this twice, once with my CMake generated makefile that includes this cmake line:
FIND_PACKAGE(wxWidgets REQUIRED richtext aui adv html core xml net base)

So without looking I imagine, there are 8 linked libraries -- none which are needed.

Just for clarity this is what I used when compiled it the second time:

clang++ ../hello.cpp -ohello_not_linked_wxwidgets

Here is the full CMakeLists.txt for anyone interested:

cmake_minimum_required(VERSION "3.10.2")

set(PROJECT_NAME "hello_linked_wxwidgets_lib_but_not_used")



FIND_PACKAGE(wxWidgets REQUIRED richtext aui adv html core xml net base) 

    add_executable(${PROJECT_NAME} ${CMAKE_CURRENT_SOURCE_DIR}/hello.cpp

    target_link_libraries(${PROJECT_NAME} PRIVATE ${wxWidgets_LIBRARIES})

    target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})

    MESSAGE("wxWidgets not found!")

And here is the file:

int main() {
    std::cout << "hello\n";
    return 0;

The difference in size is immaterial to me, but it the executables are different sizes I'm wondering could there be a difference in how they perform. My assumption is it can't possibly hurt, but because I don't know how to test this--I can't be sure.

I there a way check that the linked and unnecessary libraries don't interfere with the actual procedures called, or at least an authority that says don't worry?
Last edited on
Not an authority, but my 2 cents anyway :)

windows has depends.exe which tells what DLLs the executable needs, which implies what is buried in the code somewhat. Don't know what unix uses for this. Static libraries are put into the executable file, but I am not sure if it gets trimmed or is a flat dump when it optimizes. They seem to eat about as much space as they do when used, in my experience, but I have never worried about exe size (well, not since .com extensions were a thing lol) much in my career.

The executable code is fetched into memory, even unused parts. But c++ compilers are very aggressive at removing unused bits when they make the executable. Apart from a little extra disk spinning and a little wasted memory, its probably not having any major impact. If you linked everything known to man in there, those would become serious issues at some point, but a few extra -- you won't know the difference on today's computers.

all I can offer is that if you really want to know, do something small but high performance and get it running as fast as you can with a timer -- something that takes a second or two to run, eg sorting a trillion characters. Then add a bunch of junk it does not need to it, add some extra standard lib includes too. See if it runs just as well. May want to do this on several compilers. At the end of the day, this IS a compiler question, more than a "c++" question. Some compilers may do something dumb with the bloat.
Last edited on
jonnin wrote:
windows has depends.exe which tells what DLLs the executable needs

If you are referring to Dependency Walker, that hasn't been updated since 2006. I've used it in the past and it chokes on newer exe files and Windows versions.

Someone has rewritten/updated the app:
Topic archived. No new replies allowed.