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 560282 - Cross-compilation and field offsets
Cross-compilation and field offsets
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: build
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks: 696773
 
 
Reported: 2008-11-11 05:53 UTC by Owen Taylor
Modified: 2018-02-08 11:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proof of concept (2.38 KB, text/plain)
2015-03-13 16:58 UTC, Allison Karlitskaya (desrt)
Details

Description Owen Taylor 2008-11-11 05:53:12 UTC
The field offset computation in giroffsets.c won't work when cross-compiling.

 - There is usage of size/alignment information from libffi, which
   is right for the host environment instead of the target environment.

 - The enum-width computation trick also depends on the host and target
   environments being the same.

So, this needs at some point to be reworked a bit to do the determination
of ABI specifics in configure.ac.

 - Some things (like the widths of the enums) can be checked
   with AC_CHECK_SIZEOF()

 - Other things could probably be handled by doing magic similar
   to the way AC_CHECK_SIZEOF() works, though not sure how worthwhile
   figuring out deep magic is.

 - The remainder can be mopped up by doing runtime checks and allowing
   overriding the checks with a cache file.

   (http://library.gnome.org/devel/glib/stable/glib-cross-compiling.html 
   describes using a cache from a user perspective.)
Comment 1 Colin Walters 2008-11-11 18:50:35 UTC
For now we should add a check to abort if cross-compiling then probably.
Comment 2 André Klapper 2015-02-07 17:16:14 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 3 Allison Karlitskaya (desrt) 2015-03-13 16:58:03 UTC
Created attachment 299339 [details]
proof of concept

Here's a proof of concept for what I expect a solution to this problem would look like...
Comment 4 Allison Karlitskaya (desrt) 2015-03-13 17:00:55 UTC
Basically, we produce a binary that contains an array of ints with constant expression initialisers (sizeof, struct offsets, etc).  We put magic values on either side of that array and then we scan the resulting compiler output for those magic values in order to discover the values of the expressions we put in.
Comment 5 Emmanuele Bassi (:ebassi) 2018-01-25 16:31:13 UTC
Cross-compiling introspection data is basically a lost cause anyway, given that we need to generate, compile, and run code to introspection all object-like GTypes for properties, signals, parent types, and implemented interfaces.

The recommended best practice for cross-compilation is to actually run the scanner under a wrapper script like qemu-arm-static; that approach requires a native build of gobject-introspection in any case, and that's not a huge deal.
Comment 6 GNOME Infrastructure Team 2018-02-08 11:46:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/6.