CODEWITHSUNDEEP
c++linuxgccc++11
Philip Bennefall
Philip Bennefall

Reputation: 1487

Minimizing dependencies for Linux shared library

I am writing a shared library that I am deploying under Windows, Linux and Mac. On the Linux side, I am attempting to make sure that my library has as few dependencies as possible. I don't want the end developer to have to worry at all about what my library uses internally, and in particular I don't want to force them to install anything.

When I run ldd on my library at the moment, I see:

    linux-gate.so.1 =>  (0xf57fe000)                                        
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb773d000)     
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7654000)   
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74a1000)                 
    /lib/ld-linux.so.2 (0xb7782000)                                         
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb745d000)                 
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7440000)

This looks fairly reasonable to me, but some of these libraries I am not really sure what they are. Can anyone tell me whether this list of dependencies is reasonable, or whether I can get rid of some of these? With this list of dependencies, will my library run on a wide array of Linux configurations and distros? That is what I am aiming for, maximum portability.

When compiling, I am specifying the flag -static-libgcc. Are there any more flags I can specify to link in the C++ standard library as well, for example? Internally my library uses std::thread in C++11, but I don't want to force the application writer to necessarily have that available (if they are using an older version of GCC for instance).

Update:

I am now specifying -static-libstdc++, in addition to -static-libgcc. My dependency list now looks as follows:

    linux-gate.so.1 =>  (0xf57fe000)                                        
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7737000)     
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7584000)                 
    /lib/ld-linux.so.2 (0xb77a2000)

The only ones that cause me concern are libc.so.6, and linux-gate.so.1. I don't know what these are. Are they old, and if so have they remained backwards compatible for a long time? If so I will just keep them linking dynamically, but otherwise I have to continue investigating. Any tips would be appreciated.

Upvotes: 1

Views: 946

Answers (1)

Gavin Perkins
Gavin Perkins

Reputation: 693

linux-gate.so.1 is a virtual DSO, meaning it doesn't really exist. The best way to explain it is just to read this link Here.

To answer your question, I think your best choice is to continue linking dynamically to both of them and do a few different builds to target different distros. I have found that typically when you build for Ubuntu, it will work on several of the Debian linux systems.

Upvotes: 1

Related Questions