[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