libgcc9 and other ports that will never build on my system

[Eric Gallager]

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