Opened 2 years ago

Last modified 13 months ago

#65939 assigned defect

libunwind: do not force +universal on <11, perhaps?

Reported by: barracuda156 Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: powerpc, snowleopard, rosetta Cc:
Port: libunwind

Description

Trying to install libunwind on 10.6.8 Rosetta gives an error:

macmini:context svacchanda$ sudo port -v -n install libunwind
--->  Computing dependencies for libunwind....
Error: Cannot install libgcc for the archs 'ppc x86_64' because
Error: its dependency libgcc12 cannot build for the required archs.

The cause is this:

    variant universal   {}
    if {$universal_possible} {
        default_variants +universal
    }

Why it is there at all? If it is not required for old systems where we can have both PPC and x86, perhaps do not force +universal for those?

While some ports can be built with universal being ppc+x86, I am quite sure Macports GCC [presently] cannot.

Change History (6)

comment:1 Changed 2 years ago by kencu (Ken)

For your rosetta setup you should override base and set your universal archs in macports.conf to just ppc

comment:2 in reply to:  1 Changed 2 years ago by barracuda156

Replying to kencu:

For your rosetta setup you should override base and set your universal archs in macports.conf to just ppc

Sure, I can easily solve this issue locally for myself via macports.conf or invoking -universal, but why is it forced in the first place? I mean, I am not gonna fight for this, but such setting creates problems on older OS. Not just Rosetta – it gonna turn a big problem on 10.5.8 with perfectly legitimate ppc+ppc64.

comment:3 Changed 2 years ago by mouse07410 (Mouse)

perhaps do not force +universal

Please-please-please, drop the stupid default +universal. It makes absolutely no sense now.

This comment applies to the majority of the ports, if not to all of them.

comment:4 Changed 2 years ago by kencu (Ken)

Jeremy set up a few ports to build universal by default, to allow the buildbot to have the right binaries always available.

On 10.6 and up, this is fine, and should not change.

For 10.4 and 10.5 (and 10.6 on PPC / Rosetta) macports current default universal archs don't match what the non-system gcc (and clang) compilers can build. I asked three or four years ago for the universal arches on these systems to be changed to what the toolchain could build, but this request was declined vociferously.

So you're stuck. You could put forth a PR to disable universal building of libunwind and libcxx on such systems if you like.

Version 0, edited 2 years ago by kencu (Ken) (next)

comment:5 in reply to:  4 Changed 2 years ago by barracuda156

Replying to kencu:

You could put forth a PR to disable universal building of libunwind and libcxx on such systems if you like.

I will try :)

There are some ports which happen to be holy cows (like Pythons), hopefully this is not one of those.

comment:6 in reply to:  3 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to mouse07410:

Please-please-please, drop the stupid default +universal. It makes absolutely no sense now.

This comment applies to the majority of the ports, if not to all of them.

The majority of ports do not enable the universal variant by default. Only an extremely small subset of ports default to the universal variant and they do so for specific presumably good reasons.

The reason why libunwind does this is because it is a depedency of libcxx, as explained by the commit that first enabled it. The idea, presumably, was that someone might install libcxx, and all ports would then automatically use that libcxx even if no dependency had been declared, meaning that normal MacPorts functionality for ensuring dependencies had the right architectures would not take effect, so it was necessary to ensure that libcxx and all of its dependencies had all possible architectures.

In fact, the libcxx port doesn't install anything on 10.7 and later since the OS already includes it so perhaps defaulting to universal is not needed for these ports on 10.7 and later.

Note: See TracTickets for help on using tickets.