[MacPorts] #64863: base: (linux) invalid `os_arch` on debian-based distros

MacPorts noreply at macports.org
Sun Mar 20 19:32:11 UTC 2022


#64863: base: (linux) invalid `os_arch` on debian-based distros
--------------------+--------------------
 Reporter:  harens  |      Owner:  (none)
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  base    |    Version:
 Keywords:          |       Port:
--------------------+--------------------
 I'm currently running MacPorts on Raspberry Pi OS with an armv7l
 processor. `os_arch` is set to "armv7l" rather than the standard "arm"
 which causes breakages for ports that have a `platform arm` block.

 I think this is due to this code snippet from [https://github.com/macports
 /macports-base/blob/master/src/macports1.0/macports.tcl macports.tcl]:

 {{{#!tcl
 # set up platform info variables
 set os_arch $tcl_platform(machine)
 # Set os_arch to match `uname -p`
 if {$os_arch eq "Power Macintosh"} {
     set os_arch "powerpc"
 } elseif {$os_arch eq "i586" || $os_arch eq "i686" || $os_arch eq
 "x86_64"} {
     set os_arch "i386"
 } elseif {$os_arch eq "arm64"} {
     set os_arch "arm"
 }
 }}}

 The issue is that`uname -p`isn't defined on all linux distributions. Most
 notably, it's not defined on debian-based distros (excluding ubuntu and
 its derivatives). See [https://unix.stackexchange.com/a/307960 here] for
 an explanation why.

 As a result, the output of `uname -p` is `unknown`, which doesn't match
 with any of the if statements. Somehow though, MacPorts sets `os_arch` to
 armv7l, which is the output of `uname -m`.

 The easiest fix might be to check `uname -m` if `uname -p` is unknown e.g.
 set os_arch to arm if `uname -m` begins with arm.

-- 
Ticket URL: <https://trac.macports.org/ticket/64863>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list