[MacPorts] #58646: gcc8 @8.3.0_4 +universal: does not build/install universal libraries

MacPorts noreply at macports.org
Sun Jul 21 05:22:28 UTC 2019


#58646: gcc8 @8.3.0_4 +universal: does not build/install universal libraries
------------------------+--------------------
  Reporter:  Ionic      |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:
Resolution:             |   Keywords:
      Port:  gcc8 gcc9  |
------------------------+--------------------

Comment (by Ionic):

 Replying to [comment:17 jmroot]:
 > It's hard to tell what you're saying the actual problem is with all the
 back and forth in the comments.

 Okay, let me summarize what happened.

   1. OpenBLAS was installed +universal (and with other variants) at some
 point in the past
   2. libgcc9 was automatically installed as some dependency with the
 default variants, i.e., -universal
   3. OpenBLAS was updated, uses compilers-1.0 PG which adds compiler
 variants and explicitly depends on the default libgcc port (which is
 libgcc9 currently for most OS versions)
   4. upgrading OpenBLAS fails because it can't link libraries from libgcc9
 for the universal architecture(s) and base/port does not try to rebuild
 the dependency libgcc9 with +universal

 > A few things that seem relevant though:
 >  * libgcc is noarch. That's technically correct, but means no
 architecture requirements are enforced on its dependencies.

 Could be a problem if the path-based dependency in compilers-1.0 picked
 the libgcc port, but that really can't happen. Either libgcc is a proper,
 non-noarch port or a different non-noarch port will satisfy the
 dependency.

 >  * You can't depend on a variant. (The famous #126)

 Not relevant in this case, I think.

 >  * If a port is installed with an explicitly negated variant, that
 variant will stay negated across upgrades unless explicitly enabled.

 That's probably causing the trouble described here. Isn't it better to
 rebuild dependencies with the same set of variants as enabled on the port-
 to-be-upgraded? Otherwise users will always run into this sort of
 problems:

   1. portA installed -universal; portB installed +universal
   2. portA and portB both depend (directly or indirectly) on portC
   3. portA is updated
   4. portC is installed -universal on portA's upgrade
   5. portB is upgraded later, but portC not rebuilt with +universal
   6. fail, user needs to fix situation manually (reinstalling portC
 +universal)

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


More information about the macports-tickets mailing list