[MacPorts] #61750: base prefers arch of terminal in use rather than machine arch when installing ports

[MacPorts]

#61750: base prefers arch of terminal in use rather than machine arch when
installing ports
----------------------+----------------------
  Reporter:  raw-bin  |      Owner:  (none)
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  base     |    Version:
Resolution:           |   Keywords:
      Port:           |
----------------------+----------------------

Comment (by ryandesign):

 Replying to [comment:7 kencu]:
 > Replying to [comment:5 ryandesign]:
 > > Replying to [ticket:61750 raw-bin]:
 > > > {{{
 > > > $ sudo port install cmake
 > > > Password:
 > > > --->  Computing dependencies for cmake
 > > > --->  Fetching archive for cmake
 > > > --->  Attempting to fetch cmake-3.19.1_0.darwin_20.x86_64.tbz2 from
 https://mse.uk.packages.macports.org/cmake
 > > > --->  Attempting to fetch cmake-3.19.1_0.darwin_20.x86_64.tbz2 from
 https://lil.fr.packages.macports.org/cmake
 > > > --->  Attempting to fetch cmake-3.19.1_0.darwin_20.x86_64.tbz2 from
 https://cph.dk.packages.macports.org/cmake
 > > > }}}
 >
 > MacPorts is clearly trying to build the x86_64-only version, which it
 should not do on an arm64 Mac.
 >
 > NB: from his build line:
 > {{{
 > -arch x86_64 -O3 -DNDEBUG -arch arm64
 > }}}
 >
 > so it's trying to build it universal. If it was only trying to build
 x86_64, he would be fine (wrong, but fine), as all his deps seem to be
 x86_64.

 Right here:
 > > > {{{
 > > > --->  Attempting to fetch cmake-3.19.1_0.darwin_20.x86_64.tbz2 from
 https://mse.uk.packages.macports.org/cmake
 > > >                                                    ^^^^^^
 > > > }}}
 ''MacPorts'' is trying to build x86_64. The fact that `-arch arm64`
 appears in the log is a separate bug, perhaps in the cmake build system.
 Look at the environment variables in the log. MacPorts isn't asking for
 `-arch arm64` to be there. cmake's build is adding that all on its own.


 Replying to [comment:32 jmroot]:
 > So we pieced together in IRC that it is and isn't the terminal. User had
 a universal base installed from the pkg, and ran it from a terminal
 emulator that was x86_64 only. Being x86_64, this ran the x86_64 slice of
 the shell which ran the x86_64 slice of the MacPorts tclsh. This naturally
 causes tcl_platform to report x86_64. MacPorts is defaulting to building
 for the arch it is running as, which can be unexpected if you don't
 realise that your shell is running in Rosetta, but it's not really
 incorrect.

 Back in September when macOS 11 was in beta another DTK user observed this
 problem, and we came to the same conclusion: that processes started from a
 Rosetta 2 process will themselves run in Rosetta 2 or at least default to
 seeing the environment as x86_64. We were seeing the problem with iTerm2,
 which at that time did not have an Apple Silicon version. It has one now,
 but if the Run In Rosetta checkbox is checked in iTerm2's Get Info window,
 then the problem can still be seen, even outside of MacPorts. In iTerm2
 running in Rosetta 2, running `uname -m` shows "x86_64". On the other hand
 running `arch -arm64e uname -m` shows "arm64". I recommended to that user
 that they either use Apple Terminal (or another terminal compiled
 universal), or else explicitly start an arm64e shell by running e.g. `arch
 -arm64e zsh`.

 At the time we didn't have a MacPorts installer for macOS 11 so we were
 building from source, which wouldn't have been a universal build. But
 looking at a non-universal build of MacPorts on Apple Silicon today, I
 can't reproduce the problem. Maybe we changed something in MacPorts or
 Apple changed something in macOS since then.

-- 
Ticket URL: <https://trac.macports.org/ticket/61750#comment:34>
MacPorts <https://www.macports.org/>
Ports system for macOS