After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764116 - doc: explicitely specify if typelib is or not arch dependent
doc: explicitely specify if typelib is or not arch dependent
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: docs
unspecified
Other All
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-03-24 04:27 UTC by Nicola Fontana
Modified: 2017-09-11 01:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Enhance doc (1.13 KB, patch)
2016-03-24 04:27 UTC, Nicola Fontana
none Details | Review
I screwed the old docblock. (938 bytes, patch)
2016-03-24 04:30 UTC, Nicola Fontana
none Details | Review
Reword to say typelib is portable *but* the endianness of its scalar values (1.06 KB, patch)
2016-03-25 17:35 UTC, Nicola Fontana
committed Details | Review

Description Nicola Fontana 2016-03-24 04:27:15 UTC
Created attachment 324645 [details] [review]
Enhance doc

From what I understood from bug 592311 comment 18, the typelib format depends on the endianness of g-ir-compiler: explicitely say so in the doc.
Comment 1 Nicola Fontana 2016-03-24 04:30:03 UTC
Created attachment 324646 [details] [review]
I screwed the old docblock.
Comment 2 Colin Walters 2016-03-24 18:52:50 UTC
Review of attachment 324646 [details] [review]:

Sure. I'd also note that what the typelib is *describing* is also architecture-independent.
Comment 3 Nicola Fontana 2016-03-25 17:34:27 UTC
So it is the other way around: apart the endianness everything is portable.

Ok, I updated the patch to reflect this fact: fill free to reword it.
Comment 4 Nicola Fontana 2016-03-25 17:35:40 UTC
Created attachment 324765 [details] [review]
Reword to say typelib is portable *but* the endianness of its scalar values
Comment 5 Emmanuele Bassi (:ebassi) 2017-05-04 21:06:51 UTC
Review of attachment 324765 [details] [review]:

Sorry for taking this long.

LGTM.
Comment 6 Rico Tzschichholz 2017-09-10 08:24:41 UTC
commit dbf2106c68829141403c4877b4ed8dffaf6802c5
Author: Nicola Fontana <ntd@entidi.it>
Date:   Thu Mar 24 05:15:51 2016 +0100

    docs: manifest typelib format portability
    
    Apart the endianness of its scalar values the typelib binary format
    must be considered arch-independent: make it clear in the docs.
Comment 7 Giovanni Campagna 2017-09-11 01:57:22 UTC
This is in fact incorrect: both the typelib and the gir are architecture dependent.
They are generated from information that comes after (architecture-dependent) preprocessing of C sources.

In the extreme case, the API could be architecture dependent, as in
#ifdef __x86_64__
void example_foo_bar (void);
#endif
will add the .foo_bar() function only on x86_64.

In the common, and real case, macro values containing integer sizes, minimum and maximum values (eg. G_MAXINT) are architecture dependent and are copied verbatim in the gir and typelib.