multi-ask

[chilli.namesake at gmail.com]

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 <ryandesign at macports.org> 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.
>