libgcc9 and other ports that will never build on my system

[Bill Cole]

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?

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.


> 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.

> 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