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.

Solution 1

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 CFLAGS, where it has no business of being. In fact, most of the time you should not have $(PATH)/libmxml.a, but -L$(PATH) -lmxml instead. That should still go in LDFLAGS, but gcc won't complain if this makes it to the compiler command-line too.

Solution 2

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

Solution 3

Linking the shared library libgstmatroskademux.la against the static library

This is warning you that if you e.g. 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.

Comments

[Employed Russian]

Linking shared libraries to static ones is perfectly possible, and often desirable on UNIX.

[Jan Hudec]

Hm, I was mistaken by the second warning. Now I see the static library was included in CFLAGS, I rewrote the answer. Still of course while linking shared libraries to static ones is possible, it's definitely not something one should be doing regularly. Rather it's a really big can of worms.

[Jeegar Patel]

Hey thanks i have just put -L$(PATH) in LDFLAGS and -lmxml in GST_LIBS and magic worked no warning...!!! thanks man..!!

[Jan Hudec]

@Mr.32: Yes. I suppose the compiler found both static and dynamic mxml and chose the dynamic one when you gave it the chance. Which it really should; even if you didn't have problems with the position-independence, you would have problems when another plugin also wanted to use mxml. With dynamic linking there will be one copy and everything will be fine, but with static there would be two and hard to debug problems could appear.