Re: Portability of GIR files

[Phil Clayton <phil clayton lineone net>]

12/03/15 03:47, Philip Chimento wrote:
> On Wed, Mar 11, 2015 at 2:54 PM, Phil Clayton <phil clayton lineone net
> <mailto:phil clayton lineone net>> wrote:
>
>     I've been assuming that GIR files are portable and using them to
>     generate (equally) portable binding code.  I've found that they're
>     not in one detail: the filename in the shared-library attribute
>     looks to assume GNU ld.  For example:
>
>        <namespace name="GObject"
>                   version="2.0"
>                   shared-library="libgobject-2.0.so.0"
>
>     On Mac OS X, I think we would have libgobject-2.0.0.dylib instead.
>
>     Can it be assumed (sometimes|mostly|always) that
>
>        1. On GNU/Linux this name is the 'SO name' with form:
>             <name>.so.<so-version>
>
>        2. On Mac OS X this name has the form:
>             <name>.<so-version>.dylib
>     ?
>
>
> On OSX the shared-library attribute has the full path to the
> librar(y/ies), including the .dylib extension:
>
> shared-library="/path/to/lib/libgobject-2.0.0.dylib"
>
> Here's the code that figures it out:
> https://git.gnome.org/browse/gobject-introspection/tree/giscanner/shlibs.py#n55
> It takes ldd output and outputs the full path in the case of OSX.

I think I follow.  On OS X, it's the first field from the 'otool -L' 
output (which is probably derived from the argument to the -install_name 
linker option).

One thing - I don't follow the "lib*%s" part of the pattern - I read 
that as allowing zero or more "b"s!


>     If that is always the case, could GIR files be made portable, e.g.
>        <namespace ...>
>          <shared-library name="gobject-2.0" so-version="0"/>
>          ...
>        </namespace>
>
>     Also, is there any other way in which GIR files are not fully portable?
>
>
> I would not call this "unportable", but rather "installation-specific"
> in the same way that, for example, a pkg-config file is also
> "installation-specific".

Right - instead of 'not portable', I meant to say 'platform-dependent', 
which I would consider that synonymous with 'target-specific' or 
'installation-specific'.

Thanks to all for updating the docs too.

Phil