Thanks Ryan, that's answered everything. The reason I chose Mojave was because it is the last macOS to support running 32-bit applications, but obviously my research was not deep enough. Since it can not build 32-bit applications... looks like I'll be backing up the Mojave install and replacing wih High Sierra.
Thanks again. Best, Chilli > On Nov 21, 2021, at 07:41, Ryan Schmidt <[email protected]> wrote: > > On Nov 20, 2021, at 12:19, Chilli wrote: >> >> Hi mailing list participants. >> >> I'm going to introduce several topics. At your choice, leisure and >> convenience, a response to any is appreciated. >> >> 1) First of all, as a user, I am tremendously grateful to all the macports >> developers. MacPorts is really great stuff. Well done. > > Welcome. I'm glad MacPorts is useful to you! > > >> 2) I wrote a simple script to build and install all the ports I usually >> install, and I was astounded that, after about 12 hours, it completed >> successfully without any build errors. This is on a Late 2012 Mac mini >> running Mojave. To be clear, I was surprised my script worked rather than >> that macports works (I knew that already). >> >> >> 3) Running same script on mid 2011 Mac mini running Mountain Lion also >> completed successfully, but by the time the script completed, there were >> updates. Specifically, advancemame was listed as out of date, like this: >> >> advancemame 3.9_0 < 3.9_0 (C++ stdlib libstdc++ != >> libc++) >> >> I run port -vsN upgade outdated, and the build ultimately fails with the >> message: >> >> advancemame is using libstdc++ (this installation is configured to use >> libc++) >> Error: Port advancemame is still broken (cxx_stdlib mismatch) after >> rebuilding it more than 3 times. >> >> I doubt Mountain Lion is still supported, and I'm not sure I care too much >> as I am running advancemame @0.106.1_0 on a 2010 MacBook Pro with a macports >> install I am no longer updating, and it works just fine. >> >> But I thought I'd ask why the 2011 Mac mini Mountain Lion port build for >> advancemame is choking. >> > Because you've found a bug! Please file a bug report in the issue tracker. > > On Mac OS X 10.6-10.8, the default C++ stdlib is libstdc++ but MacPorts > enforces the use of libc++ for greater compatibility with newer software. > Successful enforcement requires the build system to use the CXXFLAGS MacPorts > tells it to use. Evidently advancemame's build system has a bug where it does > not do that. We'll need to find where and fix it. This problem would not be > seen on OS X 10.9 or later which default to libc++ already. > > Looks like advancemame hasn't had a release since 2018 and the port has no > maintainer. You may be happier with the mame port which is maintained and > gets regular updates. > > >> >> 4) On both the 2011 and 2012, no matter what I set the macports.conf >> build_arch to (x86_64, x86_64 i386, or i386), I can't get either baskiliskii >> or sheepshaver to build. Regardless of port or build_arch (in this example, >> i386) the error is >> >> Error: basiliskii cannot be installed for the configured build_arch 'i386' >> because it only supports the arch(s) 'i386'. >> >> I get the same errors with sheepshaver, which is somewhat confounding. Any >> information regarding this puzzle is appreciated. > > Basilisk II and SheepShaver are related software, so it's not surprising > their portfiles are set up in similar ways. > > They're both set up in somewhat unusual fashion, supporting only i386 on > Intel machines and only ppc on PowerPC machines. > > On your 2012 machine running macOS 10.14 Mojave, you cannot build i386 > software. (Apple removed that capability in 10.14.) To build i386 software, > you need macOS 10.13 High Sierra or earlier. > > On your 2011 machine running Mountain Lion, MacPorts should automatically > build the dependencies universal for i386 & x86_64 (assuming that's what your > universal_archs is set to in macports.conf, which it should be and is by > default), and then build sheepshaver or basiliskii for i386. You don't need > to and should not change build_arch in macports.conf from its default value > of x86_64. build_arch must be a single value. > > The sheepshaver port unusually offers a variant called +SixtyFour which, if > selected, causes the port to build for x86_64 instead. That will avoid the > need to build the dependencies universal (on macOS 10.13 and earlier) / will > allow the port to be built at all (on macOS 10.14 and later). To install the > port with this variant: > > sudo port clean sheepshaver > sudo port install sheepshaver +SixtyFour > > Neither of these ports have maintainers, and my recollection of these > software programs from years ago is that they weren't very good. Maybe they > have improved over the years, but our ports for them haven't been updated in > 3-4 years. If you or anyone wants to volunteer to update / improve them > please do. > > My preferred old macOS emulator is minivmac (I maintain the minivmac and > minivmac-devel ports and their subports), but it only emulates much older > hardware (Macintosh II and older) than either Basilisk II or SheepShaver. > > > >> >> 5) Here's where I go off the rails and likely show considerable ignorance. I >> really can't stand homebrew. I neither appreciate the metaphor nor what a >> mess it makes, and I never cared for fanaticism or penquinistas. However, >> there are a number of more recent versions of packages maintained on >> homebrew of the same earlier version package on macports, and a number of >> packages on homebrew unavailable on macports. So the idea (possible Req:) is >> this: reverse engineer homebrew packages to install through macports and >> incidentally in the process of rolling homebrew packages into macports, fix >> what is broken in homebrew, have the packages install the macports-way and >> be available for management and updates through macports and without wasting >> resources with any dedicated macports maintainers for homebrew packages. I'm >> not sure how this could be implemented, and I certainly don't want a >> marriage of macports and homebrew, nor an emulation layer for homebrew in >> macports, but more like the macports assimilation of homebrew packages with >> nothing at all changing with the macports interface. Maybe all homebrew >> packages would just be listed as a separate macports category "(homebrew)," >> if that doesn't cause too much confusion with properly categorized ports at >> a different version. What do you think of that? Possible? Worthwhile? >> Granted, this idea is not completely formed, but ultimately the goal is to >> reveal homebrew for what it really is, a sloppy and superfluous package >> manager. > > I was contacted by the Homebrew people some years ago about better > cooperation between our projects, but I didn't follow up on it. > > I don't see any way to accomplish what you want here. I have no knowledge > about how Homebrew works internally, other than that its formulas are written > in Ruby whereas MacPorts Portfiles are written in Tcl. I would assume there > are virtually zero similarities in the ways our respective projects work, so > that portfiles/formulas written for one will not be translatable to the other > system without human intervention. > > In my opinion, the correct solution for any missing or outdated port in > MacPorts is that someone should contribute a new port or a port update. This > already happens dozens (hundreds?) of times a day so it's a well-established > process. >
