(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 <[email protected]> wrote: > > On Mon, Sep 12, 2022 at 9:29 AM Bill Cole > <[email protected]> wrote: >> On 2022-09-12 at 01:29:31 UTC-0400 (Mon, 12 Sep 2022 01:29:31 -0400) >> <[email protected]> >> 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 >> [email protected] or [email protected] >> (AKA @grumpybozo and many *@billmail.scconsult.com addresses) >> Not Currently Available For Hire
