[Spice-devel] [PATCH spice 03/18] build-sys: build a noinst libtest.la to link to

[Frediano Ziglio]

> > > 
> > > Hi
> > > 
> > > On Wed, Dec 16, 2015 at 10:44 AM, Frediano Ziglio <fziglio at redhat.com>
> > > wrote:
> > > > You are not... convenient library should not be linked to programs!
> > > > Is in libtool documentation.
> > > 
> > > https://www.gnu.org/software/libtool/manual/html_node/Static-libraries.html
> > > "The key is remembering that a convenience library contains PIC
> > > objects, and can be linked where a list of PIC objects makes sense;
> > > i.e. into a shared library. A static convenience library contains
> > > non-PIC objects, so can be linked into an old static library, or a
> > > program. "
> > > 
> > 
> > Yes, I was referring to this.
> > 
> > > Having -static or not doesn't change the result. All objects are
> > > compiled with -fPIC. And ar of PIC objects + ld/elf is fine linking a
> > > program or a library that way. Searching a bit over the web, it seems
> > > to be a common practice for quite a while. Do we care so much about
> > > other non-elf compilers/linkers that could in theory have issues? Even
> > > win32 dll are fine with this (I created a small project to test this
> > > attached). Do you know an arch/compiler that wouldn't support this?
> > > 
> > > What are the alternatives? To compile the library twice and pass all
> > > the needed library flags when linking? I don't think we need to do all
> > > that for something hypotetical we can't  test.
> > > 
> > 
> > Why using a static library is so bad?
> > Here would be perfect and working on all possible (and impossible)
> > platforms.
> 
> That's worse, you get a warning from libtool:
> 
> libspice_server_la_LIBADD = libserver.a
> 
>   CCLD     libspice-server.la
> *** Warning: Linking the shared library libspice-server.la against the
> *** static library libserver.a is not portable!
> 

This patch refers to libtest, not libserver!
libserver is a convenience library used (correctly) to make a shared
library.

Frediano