I have the following problem, which seems not to have a nice solution.
For example, I have an CLI utility which uses libtiff and libX11. I want to produce two versions of this utility: dynamically linked and statically linked (with as many dependences compiled-in as possible).
For dynamic linking everything works as a charm: one need to specify -ltiff -lX11 and linker will produce a nice executable referring libtiff.so and libX11.so.
The situation becomes worse for static linking. When I use the following command:
g++ -static-libgcc -Wl,-static -o my.out *.o -lc -ltiff -lX11
it ends with missed symbols in libtiff.a and libX11.a. OK, I can put all libraries they depend on into row:
g++ -static-libgcc -Wl,-static -o my.out *.o -lc -ltiff -ljpeg -lz -lX11 -lXau -lxcb -lXdmcp
but is there any tool that makes this discovery for me? Can libtool help here (I see /usr/lib/libtiff.la but no /usr/lib/libX11.la)? Can somebody provide a basic example for libtool please? The situation is critical, if on some platform libtiff provides a narrower functionality and does not link to libjpeg which will not be available on that platform at all, so the above command for linking will fail due to unsatisfied library dependency.
The second problem is due to that warning (I believe):
/usr/lib/libX11.a(xim_trans.o): In function `_XimXTransSocketUNIXConnect':
(.text+0xcda): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
the utility is not linked statically against libc, which is still displayed in ldd output. How to correctly link statically with libX11 and libc in this case?
This question is relevant, but I think re-packing system .a files is not good idea.