What is the meaning of “Warning: Linking the shared library against static library is not portable”?

Question

I am making one dynamic library by using some function of libmxml.a library but I get this warning:

*Warning: Linking the shared library libgstmatroskademux.la against the _
*static library /home/Mr32/gst-template4_final/gst-plugin/src/libmxml.a _
is not portable!

I also get this warning:

gcc: /home/Mr32/gst-template4_final/gst-plugin/src/libmxml.a: linker _
input file unused because linking not done

So what's the meaning of this warning and how could I solve it?

Edit :

There is one already autogenerated make file for compiling the gstreamer plugin. Now to use some function of libmxml.a in that plugin I have added $(PATH)/libmxml.a in the GST_CFLAGS variable in the make file. Now, when I do make and make install , the plugin works fine, but I still get this warning.

Answer 1

Ensure that object files in libmxml.a were built with -fPIC . It's necessary to build a shared library. See also http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Here's a quick example

$ cat stat.c 
int five() { return 5; }
$ gcc -c stat.c -fPIC
$ ar crus libstat.a stat.o
$ cat dynamic.c
int ten() { return five() + five(); }
$ gcc -c dynamic.c -fPIC
$ gcc -shared -o libdyn.so dynamic.o -L. -lstat
$ ldd libdyn.so # Just to show static linkage to libstat.a
  linux-vdso.so.1 =>  (0x00007fffca1b8000)
  libc.so.6 => /lib/libc.so.6 (0x00007fc004649000)
  /lib/ld-linux-x86-64.so.2 (0x00007fc004bf7000)
$ cat main.c 
int main() { return ten(); }
$ gcc main.c -L. -ldyn
$ LD_LIBRARY_PATH=. ./a.out 
$ echo $?
10

Answer 2

Linking shared libraries to static libraries is not possible (unless you really know very well what you are doing). Don't do it.

The first warning is from libtool. It tells you, that the operation you asked for will do different things on different systems and some of those things are probably not what you want. Often it's just going to fail in various spectacular ways, because code that goes in shared and static libraries needs to be compiled with different compiler flags.

The second warning is from gcc. It is telling you that providing static library when compiling is pointless. That's because you have $(PATH)/libmxml.a in FLAGS , where it has no business of being. FLAGS有$(PATH)/libmxml.a ，它与存在无关。 In fact, most of the time you should not have $(PATH)/libmxml.a , but -L$(PATH) -lmxml instead. That should still go in FLAGS , but gcc won't complain if this makes it to the compiler command-line too. FLAGS ，但是如果这也进入编译器命令行，gcc 不会抱怨。

Answer 3

Linking the shared library libgstmatroskademux.la against the static library

This is warning you that if you eg tried to build this on 64-bit Linux, it would likely fail. That's because on x86_64, all code that gets linked into a shared library must be compiled with -fPIC flag, and code that lives in .a libraries usually isn't.

gcc: .../libmxml.a: linker input file unused because linking not done

This is warning you that you have a bogus command line. Most likely you are compiling something, and have -c on the command line (which tells GCC to stop after compiling source, and not perform linking). Since you are also supplying libmxml.a on that same command line, GCC realized that you don't know what you are doing, and warned you to think (more) about it.

Answer 4

Actually all the previous answers are wrong on the explanation of the first warning I'm afraid (especially the accepted one). The warning that the static library is not portable most likely stems from the fact that you had the path to it hard-coded (it has to do with the fact that the resulting libgstmatroskademux.la file will actually contain this path). So instead of relying on pkg-config or gcc itself to do the search of static libraries for you (which would ensure that your project compiles successfully on multiple platforms and distros) you've used fixed paths for the static library (and said path would most likely be different on other platforms). The fix is indeed to pass -L$(PATH) -lmxml to gcc (as suggested by the second part of the accepted answer) as this will ensure greater compatibility and will make the Linking the shared library ... against the static library ... is not portable! error go away as well.