[MacPorts] #67637: Universal builds with clang erroneously require clang itself to be universal

[MacPorts]

#67637: Universal builds with clang erroneously require clang itself to be
universal
------------------------+--------------------
  Reporter:  fhgwright  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  base       |    Version:  2.8.1
Resolution:             |   Keywords:
      Port:             |
------------------------+--------------------

Comment (by fhgwright):

 Replying to [comment:3 kencu]:
 > This is not a bug, the universal build of clang and LLVM was allowed to
 mean clang itself was universal on purpose, not as an oversight of some
 kind.

 That's about the host architecture, not the target architecture.

 > For one, clang and LLVM provide several libraries that other ports link
 against, and they do need to be universal at times. So the universal clang
 is needed there.

 Clang provides two completely different kinds of libraries - some involved
 in running clang itself (only related to the host architecture), and the
 compiler-rt libraries which only pertain to the target architecture.  It
 would probably be cleaner if the compiler-rt stuff were a separate
 subport, and there even seems to be upstream support for doing that.

 > For another, real universal on 10.5 and 10.6 was needed, as some 10.5
 and 10.6 installations are unable to run the 64 bit versions.

 Again, host architecture, not target architecture.

 > our gcc builds are "fake universal" and by that we mean that only the
 relevant library parts are actually universal. So the gcc builds can build
 universal software, but are not themselves universal. This has caused a
 fair bit of headache at times over the years, but it can be lived with.

 Gcc and clang are completely different.  Gcc expects the target
 architecture to be a single-valued build-time option, and the only way to
 get a gcc that builds for multiple targets is by bundling multiple gcc
 builds with a front end that selects the appropriate one.  Clang and llvm
 are fundamentally designed to make the target architecture a
 straightforward runtime option, fully decoupled from the host
 architecture.

 > Varoius folks have stumbled across the fact that a non-universal
 clang/llvm can build universal software over the years, me included -- in
 the end, they have always decided that the best thing is to have
 clang/llvm actually be universal.

 There's no need to "stumble across" something that's part of the design.
 The only reason to confuse host and target architectures is that MacPorts
 does that itself.

 > Of course, that could change, and could be worked around -- for no
 particular benefit. We are currently discussing doing the exact opposite
 move with gcc, and making it "real universal" instead of "fake universal"
 due to headaches we are having with, for example, gcc10-bootstrap and
 other gcc versions.

 The biggest problem with gcc is just that it's a horrible mess in general.

 Replying to [comment:4 jmroot]:
 > Replying to [comment:2 fhgwright]:
 > > Getting back to the exact state where this happened might be
 nontrivial, but I believe it involved a case where the chosen compiler was
 either uninstalled or outdated at the time, and when it decided to install
 or upgrade it, it specified `+universal`, probably inherited from the
 original upgrade target.  That's not the same as your test case above,
 where the chosen compiler is already active and up to date.
 >
 > OK, so that's the behaviour of all variants explicitly requested on the
 command line: they are applied to dependencies as well as the requested
 port. This might be considered a duplicate of #48051?

 If you mean the immediate command that triggered it, then no, it was just
 `upgrade outdated`.  If you mean some option on some command weeks or
 months in the past, subsequently propagating `+universal` across ports
 while confusing host and target architectures, then perhaps.

 The real problem is that MacPorts fails to properly represent host and
 target architectures distinctly, and works around some of the ensuing bugs
 with ad hoc kludges, like `depends_skip_archcheck`.  Emphasis on ''some''.
 Not to mention the way "universal" became overloaded with the introduction
 of x86_64, and more so with the advent of arm64.  I've seen builds fail
 due to confusion about whether "universal" meant "ppc+i386" or
 "i386+x86_64".

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