Filed this bug about clarifying this in the documentation: https://bugzilla.gnome.org/show_bug.cgi?id=746138 Philip On Wed, 2015-03-11 at 20:47 -0700, Philip Chimento wrote:
On Wed, Mar 11, 2015 at 2:54 PM, Phil Clayton
<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.
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".
--
Philip
_______________________________________________
gir-devel-list mailing list
gir-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gir-devel-list
Attachment:
signature.asc
Description: This is a digitally signed message part