glib2 ppc64 build "cannot make union transparent"

[ccorn@…]

Platform: PowerMac G5 running MacOS X 10.5.8 (Darwin 9)

Xcode version: 3.1.4 (providing gcc-4.0 and gcc-4.2, default is gcc-4.0)

Port: glib2 @2.28.8_0+universal (SVN -r81247)

universal_archs: ppc64 ppc

Problem: Universal build with Xcode 3.1.4's gcc-4.0 or gcc-4.2 fails with warnings like

gobject/gboxed.c:120: warning: union cannot be made transparent

and subsequent errors due to function call signature mismatches.

Using 64-bit only (-universal build_arch=ppc64) fails in the same manner.

Using 32-bit only (-universal build_arch=ppc) works.

Using configure.compiler=gcc-4.2 (default is gcc-4.0) does not make a difference.

Apparent cause: Issues with (Apple Xcode 3.1.4's) GCC-4.0 and GCC-4.2 with regard to transparent unions (cf. ​GCC type attributes) containing 64-bit pointers.

Proposed fix: The affected GCC versions should be fixed, and glib2 should probably adapt to the broken versions. Consequently, this is an upstream issue. However, for the time being, I propose a workaround for MacPorts using the attached patch.

Explanation: The offending glib2 source code uses the function macro G_DEFINE_BOXED_TYPE which itself indirectly uses G_DEFINE_BOXED_TYPE_BEGIN in gobject/gtypes.h. Depending on the GCC version, glib2 selects one of two implementations of this macro. Recent GCC versions are made to use transparent unions. The #else implementation of G_DEFINE_BOXED_TYPE_BEGIN is portable.

Patching gobject/gtypes.h to always use the portable implementation of G_DEFINE_BOXED_TYPE_BEGIN lets the universal build succeed. This is the workaround I propose.

[ccorn@…]

Proposed workaround for the "transparent union" glib2 issue

[ryandesign (Ryan Carsten Schmidt)]

You should probably report this problem to the developers of glib2 instead of to me. It doesn't seem to be a MacPorts-specific issue.

Also, consider not building 64-bit on PowerPC computers. The only reason to build 64-bit on PowerPC computers would be if you need to access more than 4GB of memory from a single program.

If I were to apply this patch to the port, I assume I should apply it only on PowerPC systems? I do have a Power Mac I can test on, but it is not a G5, so I cannot build ppc64.

[ccorn@…]

Replying to ryandesign@…:

If I were to apply this patch to the port, I assume I should apply it only on PowerPC systems?

Having no more facts to report, I leave that to your judgement.

I do not have an x86_64 machine with macports to test whether building for x86_64 reproduces the bug. I have tested only with PowerPC. The root cause seems to be an (Apple) GCC bug affecting a GCC-specific feature. I cannot safely predict further manifestations of such a bug. Therefore, restricting the patch to builds including ppc64 would be ok for me. Then the bug might or might not appear then when building for x86_64.

The patch simply switches to an upstream-provided alternative implementation of an internal glib2 macro. The alternative implementation uses less type checking due to the lack of (working) transparent unions. If both implementations worked, they would produce identical machine code. Therefore, applying the patch should be safe not just for PowerPC.

[avysk (Alexey Vyskubov)]

Cc Me!

[naesten@…]

Updated patch for glib 2.32.4

[jeremyhu (Jeremy Huddleston Sequoia)]

That's not really an acceptable patch. You might want to change it to add an ' && !defined(__ppc64__)' instead.

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Duplicate of #29026 which was fixed and the fix is in MacPorts already.