Re: embedding G-I into apps

["Andrew W. Nosenko" <andrew w nosenko gmail com>]

On Wed, Sep 10, 2008 at 11:18 PM, Colin Walters <walters verbum org> wrote:
> On Wed, Sep 10, 2008 at 3:58 PM, Stefan Kost <ensonic hora-obscura de> wrote:
>>
>> I ususally use a libtool convinience library that has everything except
>> main() and the option parsing. Then I can link my unit tests to this and can
>> also use it for gtk-doc (yes I document my app classes too). The scanner
>> could use this as well.
>
> The problem with this is (as I understand things) that a libtool
> convenience library is by default static (i.e. it's just an "ar").  We
> can't dynamically link that into the scanner.  If we build a shared
> libtool convenience library (I think this is possible), then you have
> the problem that you need to install it to the system for your app to
> work.  In other words apps using GScript/GI would need to have
> /usr/lib/myapp.so; this seems suboptimal.

Yes and no in the one time.  While libtool "convenience library"
(library from "noinst_LTLIBRARIES") is static indeed, it contains PIC
objects (if architecture requires PICs for building shared libraries).

Cite from the libtool info file, node "Static libraries":
[cite on]

   If you omit both `-rpath' and `-static', libtool will create a
convenience library that can be used to create other libtool libraries,
even shared ones.  Just like in the static case, the library behaves as
an alias to a set of object files and dependency libraries, but in this
case the object files are suitable for inclusion in shared libraries.
But be careful not to link a single convenience library, directly or
indirectly, into a single program or library, otherwise you may get
errors about symbol redefinitions.

   When GNU automake is used, you should use `noinst_LTLIBRARIES'
instead of `lib_LTLIBRARIES' for convenience libraries, so that the
`-rpath' option is not passed when they are linked.

[cite off]

-- 
Andrew W. Nosenko <andrew w nosenko gmail com>