How to combine several C/C++ libraries into one?

Question

I'm tired of adding ten link libraries into my project, or requiring eight of them to use my own. I'd like to take existing libraries like libpng.a, libz.a, libjpeg.a, and combine them into one single .a library. Is that possible? How about combining .lib libraries?

Answer 1

I'm not sure how to physically combine them into a single file, however you could employ abstraction of a sorts and just include a singe "AllMyLibs.a/h" which in turn includes everything you want. You could also put this into the location that your compiler searches for libraries, so it would work for any project.

P.S. - Out of curiousity, why do you dislike including single libs?

Answer 2

On Unix like systems, the ld and ar utilities can do this. Check out http://en.wikipedia.org/wiki/Ar_(Unix) or lookup the man pages on any linux box or through google, e.g 'unix man ar'.

Please note that you might be better off linking to a shared (dynamic) library. This would add a dependency to your executable but will dramatically reduce its size, especially if you're writing a graphic application.

Answer 3

@Ed

If, for example, I'd want to create my own static library that uses 15 others, I'd have to either include those libraries with my own, or require the end user to have them already. Both aren't really good options.

Answer 4

You could extract the object files from each library with

ar x <library name>

and then merge them all into a new library with

ar cs <new library name> <list each extracted object file>

Answer 5

I'd like to ask a question about the question (now that it has been answered):

I'm wondering why this is an issue? Once your makefile is set up which includes all of the libs you want/need to add, building your code becomes a snap. Are you compiling your stuff from the command line without using makefiles or some form of build helper?

Am I missing something?

Answer 6

It's a problem when I want to distribute my own static library, and either have to compile it using source distributions of required libraries, or to require those libraries be linked with the project by the end-user. If the number of libraries, for some of which sources are unavailable, approaches 15, neither option is really viable.

Answer 7

Maybe I'm misunderstanding, but don't you only have to ship the libs if the end-user code calls them directly? If all the access to Jpeg methods etc is from your code in your static library, then just link the libs into your lib.

I.e.

----------------
| End-user exe |
----------------
      |
      | makes calls to
      |
      v
 --------------------
 | Your static lib.a | 
 --------------------
         | makes calls to and links
         v
     ------------------------------------ .....
     |                    |         |
  -------------    -------- ---------- 
  | libjpeg.a |    |libz.a| |libpng.a|
  -------------    -------- ----------

I.e it's only an issue if end code needs to make direct calls into libz.a, libpng.a etc.

If the app code has a legitimate need to call libz.a, for example, then that would as mentioned above be a case for using a dynamic module.

PS: Do I get an artists badge? :)

Answer 8

Combining several third-party libraries into one could create more problems for you--for instance, if two of those libraries define a common symbol which your program doesn't use. Now you've got to extract all (or all-but-one) of the instances of the common symbol before you combine the libraries.