GNOME Bugzilla – Bug 780238
assertions fail on Mac OS: G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64))
Last modified: 2018-02-26 09:22:36 UTC
glib (and glib-depending applications) cannot be compiled on recent-ish Mac OS versions. The compile will complain that the following assertion in gtypes.h, in the body of `_GLIB_CHECKED_ADD_U64`: G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64)); fails with the error error: '_GStaticAssertCompileTimeAssertion_0' declared as an array with a negative size This assertion fails when programs are compiled as universal binaries. In Mac OS this is done using the non-standard options `-arch x86_64 -arch i386`. With these options a 32-bit host can compile both 32- and 64-bit programs in one go. This problem has a wide impact: basically all programs that depend of GLib cannot be compiled on Mac OS since late 2016, as reported by the Homebrew collaborators here: <https://github.com/Homebrew/homebrew-core/issues/5404>. A workaround, described at <https://github.com/fontforge/fontforge/pull/3023>, is to disable universal binaries and only compile for 64-bit OSes, but this means leaving a whole class of users behind. Another possible workaround is to #ifdef-out that assertion when compiling on Mac OS.
I would suggest to not build universal binaries if it doesn't work.
FWIW, I don't think you'll be leaving a lot of users disappointed by not offering universal builds. Apple's last release to support 32-bit Intel was Snow Leopard. Only a few Apple models were ever released to have 32-bit Intel CPUs anyway, and those machines should be around 10 years old now.
Indeed, OS X Lion (the first OS X version which was 64-bit only) was released in 2011, so I don’t think it’s unreasonable for us to drop support for universal binaries. Given that this is the only bug about it since this static assertion landed 2 years ago (commit d0219f25970c740ac1a8965754868d54bcd90eeb), it doesn’t seem like there’s been a big fall out. If someone wants to come up with a patch to make _GLIB_CHECKED_ADD_U64 work correctly if that static assertion doesn’t hold, I’ll be happy to review it. For now, I’m going to close this bug though.
Note that for at least some folks encountering this, the cause is that gobject-introspection's g-ir-scanner builds C sources via Python's "distutils" module. This reuses Python's own compile-time options, which when using the Apple-provided Python includes the "universal" dual-arch options... The resulting 32-bit portion of the build then #includes the glibconfig.h generated at glib compile time, which defines guint64 as "unsigned long"... and so the assertion fails. I'm not sure whether to consider this a packaging issue with Homebrew (they have chosen to let gobject-introspection use the Apple system Python instead of their own 64-bit Python package, which would resolve it) or a bad assumption in gobject-introspection that Python's distutils produces options that will be suitable for glib-using apps, or a bad assumption in glib that it can safely create an arch-specific file in /usr/includes. In any case, it can be worked around reliably by setting ARCHFLAGS="-arch x86_64" in the environment which overrides distutils's default compiler flag selection.
The original commit that introduced that assert also included a fallback implementation for the case when compiler builtins are not available. This fallback implementation works fine for cases where assertion is false. Fixing the compilation issue then could be done by repurposing the assert as a part of new ifdef check for selection of fallback implementation of _GLIB_CHECKED_MUL_U64. Note: I am not working on patch for this, as I currently can't test this on platform involved. BTW, I also think this is bad assumption on gobject-introspection part, that it includes various flags that had been used to compile Python.