GNOME Bugzilla – Bug 736109
build failure on x32: assumes glong = time_t
Last modified: 2016-02-14 16:21:06 UTC
Per Linus' decree, on all new platforms time_t is 64 bits long even if long (and thus glong) is only 32 bits. Too bad, currently introspection assumes these types are always identical. Fortunately, it appears time_t is never marshalled anywhere outside the test suite (I won't bet my life on this, though...) -- glib's own functions never store it, it's used merely as argument or return value. So just purging any references to time_t from the test suite might be good enough. If not, some proper support would be needed. Other types with this property are off_t and dev_t (also 64 bit on x32), but they are never referenced anywhere but an entry in the scanner.
There's a bit more info on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699024 -- useful if you don't have an x32 system at hand.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Created attachment 321118 [details] [review] patch to drop the bogus test As time_t doesn't appear to be used in any structures, this test is not needed. Thus, the attached test drops it. The assumption that time_t is same as glong is false on at least x32, arm32 and 32-bit architectures of FreeBSD and OpenBSD. The former two from their very start, the latter two had a flag day and changed this in their ABI.
A brief investigation with `git annotate` led to: https://bugzilla.gnome.org/show_bug.cgi?id=552566 Which we basically reverted later in: https://git.gnome.org/browse/gobject-introspection/commit/?id=5cb925b20739c04e18e94a03a3e4e68041894b03 Neither of these commits actually give a *real world* example of a user (which is my fault). But yeah, let's just continue on this path and drop more time_t support.
Review of attachment 321118 [details] [review]: Why drop the "char dummy9"? I assume it was there as a padding test, but OTOH it doesn't hurt to have it. Can you turn this into a `git format-patch` style patch? See https://wiki.gnome.org/Newcomers/SubmittingPatches
Created attachment 321122 [details] [review] git commit against master > Why drop the "char dummy9"? I assume it was there as a padding test, but OTOH it doesn't hurt to have it. For consistency -- every structure in that file has dummies alternating with actual fields, so I followed the rule. Of course, it doesn't really matter for me. > Can you turn this into a `git format-patch` style patch? See > https://wiki.gnome.org/Newcomers/SubmittingPatches Sure! Here it goes. Forgive me for using and testing only the Debian package the first time, but as a porter I handle a large number of packages, and thus cut corners preferring known build environment to learning every upstream's setup. So here's the second patch, built and tested against current master.
Review of attachment 321122 [details] [review]: OK.
https://git.gnome.org/browse/gobject-introspection/commit/?id=45757373ced1b50b183fb6cff44f1e6859d8cfb9 I expanded your commit message a bit and also linked to this bug.