Thanks, this advice gives me exactly what I asked for (even if it
turns out that's not what I really wanted :-).
I agree entirely that putting the framework into the main program is a
good solution, but I'm not involved with the main program's
development, so that's not an option for me.
Right now I don't want any state to be shared between separate
instances of the framework, so the scenario you mentioned (of global
variables not being squashed) is actually what I want. I believe that
I can ensure that exact behavior across the whole framework by
compiling it with -fvisibility=hidden. Hidden visibility also seems
to make sure that calls into the framework link only against their own
copies (i.e., if two plug-ins use two different versions of the
framework, the two plug-ins won't start calling the wrong versions of
the framework functions).
My hope is that this approach will protect users of the framework from
the most possible hidden linking danger.
--Justin
On Wed, Feb 3, 2010 at 5:17 AM, Andrew W. Nosenko
<andrew.w.nose...@gmail.com> wrote:
> On Wed, Feb 3, 2010 at 03:39, Justin Seyster <jrs...@gmail.com> 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 <andrew.w.nose...@gmail.com>
>
