[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Creating a partial library
Re: Creating a partial library
Wed, 3 Feb 2010 18:22:01 -0500
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.
On Wed, Feb 3, 2010 at 5:17 AM, 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>
Re: Creating a partial library, Andrew W. Nosenko, 2010/02/03