glib2 won't build correctly on PPC machines

[mtalexander (Mike Alexander)]

The configure script for glib2 can't figure out the endianness of the machine if there is a "-arch" parameter in CFLAGS and assumes little-endian with a warning. This causes problems in both the universal and non-universal builds of glib2 (for different reasons). Sometime recently MacPorts was changed to provide a -arch flag even in a non-universal build, this causes this build to assume a little-endian machine in all cases. Of course on a universal build the -arch parameter is necessary and the Portfile contains some code to deal with this. However it is incorrect and the universal build also assumes a little-endian machine in all cases.

Since the build appears to succeed (if you don't see the warning from configure), but assumes little-endian architecture, this is a somewhat subtle bug. It generates header files which may cause other programs to build incorrectly and libraries which mostly work, but fail for some calls. After fixing this bug you need to rebuild everything that depends on glib2 to be sure things will work again.

[mtalexander (Mike Alexander)]

Patch to the glib2 Portfile to fix this problem

[ryandesign (Ryan Carsten Schmidt)]

Replying to mta@…:

The configure script for glib2 can't figure out the endianness of the machine if there is a "-arch" parameter in CFLAGS and assumes little-endian with a warning. This causes problems in both the universal and non-universal builds of glib2 (for different reasons). Sometime recently MacPorts was changed to provide a -arch flag even in a non-universal build, this causes this build to assume a little-endian machine in all cases.

Maybe r53217.

Of course on a universal build the -arch parameter is necessary and the Portfile contains some code to deal with this. However it is incorrect and the universal build also assumes a little-endian machine in all cases.

Since the build appears to succeed (if you don't see the warning from configure), but assumes little-endian architecture, this is a somewhat subtle bug. It generates header files which may cause other programs to build incorrectly and libraries which mostly work, but fail for some calls. After fixing this bug you need to rebuild everything that depends on glib2 to be sure things will work again.

We had this problem before and fixed it; see #15816. But it must've broken again in a newer glib version. I discovered this myself again recently (using MacPorts 1.7.1 I'm pretty sure) and thought I had filed a ticket but I can't find it now.

[tobypeterson]

Current patch is a bit bogus - we are passing the -arch flag for a reason, because we want to allow people to force their ports to build for a specific architecture. Ideally the configure script needs to be changed to work even when the -arch flag is passed.

[mtalexander (Mike Alexander)]

I understand that, but patching the configure file is ugly and I didn't want to do that. If you really want to pass the -arch flag then you could change the port file to set ac_cv_c_bigendian appropriately in the configure environment. The universal target does this (this is the code that was broken in the port file) but the non-universal target doesn't. I won't be able to do this right away, but someone else could.

[tobypeterson]

Could just override the configure script's result by patching the config.h file appropriately. Would be much simpler if the port weren't using the muniversal crap

[edmond@…]

I just noticed this problem today. To work-around it (this is not a fix), I did the following:

% sudo port edit glib2

Then, I forced the endian-order to what I wanted, in my case big-endian, by locating the following code and commenting it out, and then placing the set for the cross_archs, host_archs and big_endian to what I wanted. The code to locate is:

        # Find architectures which will not run on build platform.
        if { ${os.arch}=="i386" || ${os.arch}=="x86_64"} {
            set cross_archs "ppc ppc64"
            set host_archs  "ppc ppc64"
            set big_endian  "yes"
        } else {
            set cross_archs "i386 x86_64"
            set host_archs  "i386 x86_64"
            set big_endian  "no"
        }

I commented out the above code (using #'s at the start of each line) and then selected what was right for me, big-endian, which was:

        set cross_archs "ppc ppc64"
        set host_archs  "ppc ppc64"
        set big_endian  "yes"

In case anyone needs a work-around - as I did.

[michael-macports@…]

What if you need it to actually build universal (PPC/i386)?

[LantzR@…]

Hiya

I had what seems to be this problem. I discovered it when reinstalling gtk2 which crashed and burned.

XRef: #20997

I'm on running OsX 10.4.11 on PPC. I have kept the default for universal builds.

Note that both glib2 and gtk2 were built and working last month, so something changed recently.

I had rebuilt glib2 on Sept 12th, then gtk2 failed as described in #20997 two days later

grep G_BYTE_ORDER /opt/local/lib/glib-2.0/include/glibconfig.h 
#define G_BYTE_ORDER G_LITTLE_ENDIAN

michael.klein@… wrote:

Workaround: set build_arch to an empty string in macports.conf and rebuild glib2. This keeps the port environment from adding -arch=ppc to $CFLAGS

$ grep build_arch /opt/local/etc/macports/macports.conf
#build_arch			i386
build_arch

For me the undocumented build_arch did not exist in macports.conf so I just added the empty one.

Uninstalled glib2 and it's dependents, installed glib2 then gtk2. It worked just fine.

I believe it did a universal build. I'll look for more info.

Cheers, Lantz

[LantzR@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to LantzR@…:

Note that both glib2 and gtk2 were built and working last month, so something changed recently.

MacPorts 1.8.0 was released. It uses the -arch flag on all builds, not just universal builds. glib2 breaks on PowerPC machines when using the -arch flag. The glib2 port includes code to work around this, but only for universal builds. Therefore, non-universal builds on PowerPC now fail.

For me the undocumented build_arch did not exist in macports.conf

Probably because you upgraded to MacPorts 1.8.0 from a prior version. MacPorts does not update your configuration files.

[LantzR@…]

Replying to ryandesign@…:

Replying to LantzR@…: MacPorts 1.8.0 was released. [snip] Therefore, non-universal builds on PowerPC now fail.

I was doing a universal build, but originally without "build_arch" in macports.conf

For me the undocumented build_arch did not exist in macports.conf

Probably because you upgraded to MacPorts 1.8.0 from a prior version. MacPorts does not update your configuration files.

True. I did upgrade to MacPorts 1.8.0.

Thanks, Lantz

[ryandesign (Ryan Carsten Schmidt)]

Replying to LantzR@…:

I was doing a universal build,

Hm, ok. I didn't think this affected universal builds.

but originally without "build_arch" in macports.conf

If build_arch is not set in macports.conf, MacPorts uses its defaults. As of MacPorts 1.8.0, "-arch" is always set, and it was my understanding this was the cause of the problem on PowerPC.

[michael-macports@…]

Cc Me!

[raphael@…]

Cc Me!

[kioarthurdane@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Fixed in r58479.

[ryandesign (Ryan Carsten Schmidt)]

Followup in r58480.