texinfo: Build fail on G4/PPC using +universal

[xanda-escuyer (xanda)]

Using the +universal flag results in build failure; see the attached main.log at line 2165:-

:info:build gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags

We need the +universal build so is there a way around this please?

[xanda-escuyer (xanda)]

Build main.log

[ryandesign (Ryan Carsten Schmidt)]

Using the muniversal portgroup would be the workaround. (Add the line PortGroup muniversal 1.0 after the PortSystem 1.0 line.) Using the muniversal portgroup can cause new issues and some ports may require additional changes beyond just adding the portgroup.

[xanda-escuyer (xanda)]

Thanks for the feedback.

How do would we try this suggestion please?

[barracuda156]

I confirm the failure on 10.5.8 on G5, so cpu is not here to blame.

[barracuda156]

Replying to ryandesign:

Using the muniversal portgroup would be the workaround. (Add the line PortGroup muniversal 1.0 after the PortSystem 1.0 line.) Using the muniversal portgroup can cause new issues and some ports may require additional changes beyond just adding the portgroup.

I guess we can add it for <11? That is, wherever gcc-4.* is used. Or alternatively (and perhaps better) conditional on GCC regardless of OS.

And yes, PG works perfectly.

[barracuda156]

It still fails:

/usr/bin/gcc-4.2 -std=gnu99 -DHAVE_CONFIG_H -I. -I../..   -I/opt/local/include   -pipe -Os -arch ppc -arch ppc64 -MT libgnu_a-cloexec.o -MD -MP -MF .deps/libgnu_a-cloexec.Tpo -c -o libgnu_a-cloexec.o `test -f 'cloexec.c' || echo './'`cloexec.c
gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
make[4]: *** [libgnu_a-basename-lgpl.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [libgnu_a-cloexec.o] Error 1
make[4]: *** [libgnu_a-argz.o] Error 1

[barracuda156]

In 48491d345c0512847d0b6df11be3038b67d3cd96/macports-ports (master):

texinfo: fix universal build with GCC

Fixes: #65995

[ryandesign (Ryan Carsten Schmidt)]

Recall when I said:

Replying to ryandesign:

Using the muniversal portgroup can cause new issues and some ports may require additional changes beyond just adding the portgroup.

The portfile says:

    configure.env-append \
        PERL_EXT_CFLAGS=[get_canonical_archflags cc] \
        PERL_EXT_LDFLAGS=[get_canonical_archflags ld]

I don't think this can work correctly with the muniversal portgroup.

And you've included the portgroup conditionally. It can be hard enough to make a port build correctly without the muniversal portgroup, or with the muniversal portgroup, but making a port work correctly whether or not the portgroup is included is an additional challenge. I don't know if we've attempted to do that in any other ports but it seems like unnecessary extra difficulty.

[barracuda156]

Replying to ryandesign:

Recall when I said:

Replying to ryandesign:

Using the muniversal portgroup can cause new issues and some ports may require additional changes beyond just adding the portgroup.

The portfile says:

    configure.env-append \
        PERL_EXT_CFLAGS=[get_canonical_archflags cc] \
        PERL_EXT_LDFLAGS=[get_canonical_archflags ld]

I don't think this can work correctly with the muniversal portgroup.

And you've included the portgroup conditionally. It can be hard enough to make a port build correctly without the muniversal portgroup, or with the muniversal portgroup, but making a port work correctly whether or not the portgroup is included is an additional challenge. I don't know if we've attempted to do that in any other ports but it seems like unnecessary extra difficulty.

I don’t mind having it unconditional, but I made it so exactly because I was told by some members that muniversal may have unintended consequences with clang.

It does work now with GCC. It was broken without muniversal.

What would you suggest? It is preferable to have an agreed-upon general solution, since many ports require a same fix to build universal with GCC. Easier solution is muniversal (should be tested per case, of course). Harder is to fix Macports GCC first so that they are genuinely universal, and then use muniversal. (In either case muniversal is needed.) Then, fixing driver-driver, but when that gonna be done…

[kencu (Ken)]

Replying to barracuda156:

What would you suggest?

Consider MacPorts "order of priorities":

1. the port needs to work on current MacOS systems, ie arm64 Macs
2. the port should work on the common less current systems, ie Intel Macs >= 10.13
3. the port should build universal on those systems
4. the Portfile code cannot be an undecipherable, unmaintainable mess of gobbledygook spaghetti
5. the port could work on older Intel systems (< 10.13)
6. the port could work on really ancient Intel and Power PC systems (< 10.6).
7. the port could build universal on really ancient systems (< 10.6).

So I would first of all say you could just disable universal building on those ancient systems and be done with this.

Or alternatively come up with a simple fix that works -- like for example if this is the issue:

gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags

then remove the offending -E, -S, -save-temps and -M options . They are useless for MacPorts builds anyway.

And then, if none of those work, and you really want muniversal on the ancient systems, then enable it always and test as many systems as you can to make sure that this works properly and doesn't break things.

Is this a lot of work? -- you bet.