libgcc9 and other ports that will never build on my system

[chilli.namesake at gmail.com]

(note: my reply all does not include the list, annoyingly)

That is pretty unsettling. 
uname -p gives i386
uname -m gives x86_86

I vaguely recall that in the past MacPorts has ignored the arch specification. If macports.conf arch setting is ignored, is there a way I can force x86_64?

Thanks.

> On Sep 12, 2022, at 11:49, Eric Gallager <egall at gwmail.gwu.edu> wrote:
> 
> On Mon, Sep 12, 2022 at 9:29 AM Bill Cole
> <macportsusers-20171215 at billmail.scconsult.com> wrote:
>> On 2022-09-12 at 01:29:31 UTC-0400 (Mon, 12 Sep 2022 01:29:31 -0400)
>> <chilli.namesake at gmail.com>
>> is rumored to have said:
>>> With Mojave on Macmini6,1 & XCode 11.3.1
>>> I get this:
>>> port -vsN upgrade libgcc9
>>> --->  Computing dependencies for libgcc9.
>>> --->  Fetching distfiles for libgcc9
>>> Error: gcc9 9.5.0 is not supported on Darwin 18 i386
>> Why are you trying to to build it for i386, e.g. 32-bit? Is there some
>> dependent that can't be built for x86_64?
> 
> There are cases where x86_64 will still get reported as i386 even
> though it isn't; on my x86_64 machine, for instance, `uname -p` and
> `arch` both report i386 even though it's x86_64.
> 
>> That's the proximal issue, but it is probably not addressable by simply
>> re-installing without the universal variant. See below.
>>> Error: Failed to fetch libgcc9: incompatible macOS version
>>> Error: See
>>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/libgcc9/main.log
>>> for details.
>>> Error: Follow https://guide.macports.org/#project.tickets if you
>>> believe there is a bug.
>>> ---------
>>> I saw a bug report was opened, but wasn't paying much attention. This
>>> was closed 2 months ago
>>> https://trac.macports.org/ticket/65415
>> Probably more relevant is this closed bug:
>> https://trac.macports.org/ticket/65518
>> The bottom line there: GCC9 9.5.0 or greater won't work on 10.11 or
>> later. Just will not. Upgrade to a later GCC, if you really need GCC.
> 
> The thing is, it used to work, though, and now I (and the original
> poster, presumably) have ports that depend on it that would break if
> we uninstalled it:
> 
> $ sudo port -vc uninstall libgcc9
> Note: It is not recommended to uninstall/deactivate a port that has
> dependents as it breaks the dependents.
> The following ports will break:
> libgcc8 @8.5.0_1
> gcc9 @9.4.0_1
> p5.28-extutils-f77 @1.260.0_0
> p5.30-extutils-f77 @1.260.0_0
> Continue? [y/N]: n
> --->  Cleaning libgcc9
> --->  Removing work directory for libgcc9
> $
> 
>>> In a couple or few other bug reports I've opened, most fixed and
>>> closed in due course, which is how I have known things to operate for
>>> the better part of 2 decades. But occasionally, some tickets are
>>> closed without the defect  being fixed, with something posted to the
>>> effect "you're not using the right version of XCode for your system,
>>> and we're not going to support it... " or similar, and I don't know
>>> what the heck they're talking about, because XCode 11 requires macOS
>>> 10.14 or later, and I don't know what other version of XCode I'm
>>> supposed to be using on Mojave. But there's a further port here, which
>>> is that some maintainers and bug fixing volunteers, those that usually
>>> fix and close bug reports, seem to want to close these tickets even
>>> though the problem still exists, as though there is a mean boss
>>> somewhere putting pressure on them to close tickets when, sometimes,
>>> the defect still exists, as though closing a ticket has some magical
>>> effect. This is just an uninformed opinion from mild exasperation.
>> Because MacPorts is downstream of all ports, there are simply some
>> problems that cannot be addressed by the MacPorts Project. Some problems
>> can't be fixed because no one who could fix it (e.g. GCC upstream)
>> considers it a problem or has a motivation to fix it. There is
>> absolutely no benefit in leaving a downstream ticket open for an issue
>> that can only be fixed upstream, but where upstream has decided not to
>> fix it.
> 
> In GCC's case it's not so much that no one is available to fix it, but
> rather that the GCC 9 branch is closed now, so fixes can't be checked
> into it even if an upstream maintainer wanted to. IIRC, though, the
> patch from newer GCCs that's required here applies perfectly cleanly
> against the GCC 9 branch, and could in fact be used here if a
> downstream maintainer wanted to include it.
> 
>>> So there's that. But the other thing is, I just don't care, if
>>> something isn't going to work, fine. But how do I get it to stop
>>> showing up in my outdated list so that I can just blanket-upgrade the
>>> outdated ports without the upgrade command failing when it reaches the
>>> problematic port? I'm sure it's in the manual somewhere, but I figured
>>> Ryan and a couple others seem to know the manual by heart and may have
>>> mercy on me and my bad eyes, and tell me how to stop a port from being
>>> reported it is outdated.
>> MacPorts isn't designed to work around ports that have been pinned at an
>> obsolete version. As long as you have libgcc9 installed via MacPorts on
>> Mojave, it will show up as outdated and fail to upgrade.
>> Options:
>> 1. Just remove libgcc9. It is old enough that there's a real chance that
>> every reason you ever had to install it no longer demands that version.
>> 2. Run 'port rdependents libgcc9' to get a list of what must be updated
>> to a modern GCC in order to work. Install a modern libgcc version and
>> rebuild those, then see #1.
>> 3. "sudo port upgrade outdated and not libgcc9" should work, but it will
>> leave everything dependent on libgcc9 at older versions.
>> --
>> Bill Cole
>> bill at scconsult.com or billcole at apache.org
>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>> Not Currently Available For Hire