Opened 8 months ago

Closed 8 months ago

Last modified 8 months ago

#69573 closed defect (fixed)

octave hardcodes powerpc64 on G5, regardless of Macports conf

Reported by: barracuda156 Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.9.1
Keywords: leopard, snowleopard, powerpc Cc: catap (Kirill A. Korinsky), Schamschula (Marius Schamschula)
Port: octave

Description (last modified by barracuda156)

Could someone say why does the port set host via this odd method?

        if { ${os.platform} eq "darwin" && ${os.major} >= 9 && [sysctl hw.cpu64bit_capable] == 1 } {
            set short_host_name powerpc64-apple-${os.platform}${os.major}.x.x
        } else {
            set short_host_name powerpc-apple-${os.platform}${os.major}.x.x
        }

This hardcodes, in effect, powerpc64, for 10.5–10.6 on G5. However, it is pretty likely everything is built for powerpc in fact (even on 10.5, while 10.6 does not support ppc64 at all).

For example, I get this:

--->  Patching configure: s|__MACPORTS_canonical_host_type__|powerpc64-apple-darwin10.x.x|g
--->  Patching subst-config-vals.in.sh: s|__MACPORTS_canonical_host_type__|powerpc64-apple-darwin10.x.x|g

But 10.6 aside, in most cases this will be wrong on 10.5.8 too.

It seems that instead configure.build_arch should be used, and that will always give a correct result.

Change History (7)

comment:1 Changed 8 months ago by barracuda156

Description: modified (diff)

comment:2 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

That code was added to the octave portfile and the octave portgroup in [5c63c9706d260f6a6557b110bb7608f0d92287bf/macports-ports] which references five tickets but none of those tickets seem to be about PowerPC.

comment:3 in reply to:  2 Changed 8 months ago by barracuda156

Replying to ryandesign:

That code was added to the octave portfile and the octave portgroup in [5c63c9706d260f6a6557b110bb7608f0d92287bf/macports-ports] which references five tickets but none of those tickets seem to be about PowerPC.

I can imagine it is correct for Intel (and do not plan to touch that part), my only point it is wrong for PowerPC.

comment:4 Changed 8 months ago by jmroot (Joshua Root)

The code is pretty clearly deliberately recording the kind of CPU that it is running on, not the architecture that is being built for. It is wrong for arm however.

comment:5 in reply to:  4 ; Changed 8 months ago by barracuda156

Replying to jmroot:

The code is pretty clearly deliberately recording the kind of CPU that it is running on, not the architecture that is being built for. It is wrong for arm however.

It is not clear to me whether this was intended and not just a copy-paste from x86 case; normally, host powerpc64 == ppc64.

  1. S. GCC has some obscure optimizations allowing for specific 64-bit insns to be emulated on G5 running in 32-bit mode (I may not describe it accurately, saying from memory), but those are pretty unsafe and, I believe, we rather not use those. Other than that, what is the use-case for recording powerpc64 for a powerpc(32) build/host?

(I recall Intel had an issue where x86_64 build could be forced into 32-bit (mlton had that issue, for example), so this hack could be addressing those.)

Last edited 8 months ago by barracuda156 (previous) (diff)

comment:6 Changed 8 months ago by barracuda156

Resolution: fixed
Status: assignedclosed

In 5571d04597554343c40d166bc0f930a45db9d926/macports-ports (master):

octave PG: fix host for ppc

Closes: #69573

comment:7 in reply to:  5 Changed 8 months ago by jmroot (Joshua Root)

Replying to barracuda156:

It is not clear to me whether this was intended and not just a copy-paste from x86 case; normally, host powerpc64 == ppc64.

I would suggest it's a bad idea to modify this without understanding why it exists.

Note: See TracTickets for help on using tickets.