Re: Creating a partial library

[Andrew W. Nosenko]

On Wed, Feb 3, 2010 at 03:39, Justin Seyster <address@hidden> wrote:
> I'm working on a support framework for plug-ins, and I'm struggling to
> come up with a way to compile it.  I'm leaning towards building it as
> a convenience library, but there a few SNAFUs.
>
> Each plug-in is itself a shared library.  I would like to avoid having
> a second shared library that the plug-in relies on for a couple of
> reasons.  Mostly, I think that the extra dependency would make it
> difficult to distribute plug-ins built with the framework, but I'm
> also worried that reverse dependencies in the framework would break if
> there are multiple plug-ins loaded that link the framework.
>
> I'm pretty sure that making the framework a convenience library is my
> ideal solution: the plug-in author will be able to distribute a single
> shared object without any non-standard dependencies.  However, I read
> that Automake does not allow installing a convenience library.  I
> verified that a regular static library (not specified with
> noinst_LTLIBRARIES) definitely does not work: the resulting .a file is
> not position independent and won't link into a plug-in.  I don't want
> to use noinst_LTLIBRARIES, though, for the simple reason that I want
> to be able to install the library!
>
> Is it worth my while to figure out a hack to make a convenience
> library install, or is there a better approach for linking this kind
> of framework using Automake?  Thanks.

There is two things:
  o  first is that you can obtain what you want (static PIC library); and
  o  second is that you should not do that

Abous static PIC libraries: You may hint libtool to use PIC code for
static library using "-prefer-pic" option and per-target flags.  E.g.
for library libfoo.a:

    LTLIBRARIES = libfoo.la

    libfoo_la_CFLAGS = -prefer-pic
    libfoo_la_LDFLAGS = -static -prefer-pic

Of course, you can use other language related flags (e.g.
libfoo_la_CXXFLAGS for C++) instead of or in addition to the
libfoo_la_CFLAGS if you use some other language instead of or in
addition to the C.

About why you should not to do that:
If you link static library into two (or more) modules then after
loading the parent process will have two (or more) symbols with one
and the same name.  With all pain as consequence.  What if these
symbols are functions and corresponds to two different version of your
library?  What if they are global variables, which correspond to
mutexes?  I can imagine the case (and saw it indid) when these mutexes
are not "sqashed" into one and therefore don't protect anything.  And
so on and so on...

Therefore, the safest way is to link your "framework" into main
process (and only into main process) and let the main process to
provide these "framework" functions to the modules loaded by him.

-- 
Andrew W. Nosenko <address@hidden>