Re: multi-ask

[Ken Cunningham]

Yeah, I guess that website name is a little bit too close to "emasculation" for 
my memory to bring it forward :>

K

> On Nov 21, 2021, at 9:40 AM, chilli.names...@gmail.com wrote:
> 
> I think you meant
> 
> https://www.emaculation.com/forum/viewtopic.php?t=7361 
> 

Re: multi-ask

[chilli.names...@gmail.com]

> I recently downloaded a prebuilt version of both basiliskii and sheepshaver 
> from the 'macemulation' website that is 64bit and runs on BigSur, and that 
> works well too.


I think you meant

https://www.emaculation.com/forum/viewtopic.php?t=7361

https://www.emaculation.com/forum/viewtopic.php?f=20&t=7360

It's been several years since I last indulged my emulation interests, and this 
site keeps coming up, but even though I recently studied instructions here for 
qumu-system-68k, I only now realize the site is (currently) central to these 
sorts of efforts. 

> There are upstream versions available that run as far back as 10.6.8 I 
> believe.


Using pre-built binaries is probably a far more practical solution here, allows 
me to keep running Mojave rather than starting over with High Sierra. 

Since responding this morning, I already imaged the internal Mojave install to 
an external partition and installed High Sierra on another external partition, 
and I was about to image High Sierra back to the internal storage when I read 
your reply. I just booted back off internal Mojave. I may keep building out 
High Sierra booting off the external partition, but now that I don't 
necessarily need to, then maybe I'll mess with it next weekend, or whenever. 
Thanks Ken.



> On Nov 21, 2021, at 12:03, Ken Cunningham  
> wrote:
> 
> When I last updated the basiliskii and sheepshaver ports I was still fairly 
> new to macports and took them on as a challenge. They had some interesting 
> wrinkles I was looking to understand.
> 
> 
> At that time, both of them did not run well when built as 64-bit versions; 
> the JIT code, that really makes them run quickly, did not work when built 64 
> bit, and the networking stack had not been fixed to build and run 64 bit. Of 
> course, at that time, macOS supported i386, and we were (most of us) unaware 
> that 32bit Intel support was about to disappear.
> 
> 
> So the ports were set up to force both of them to build as 32bit versions, 
> which worked. I allowed a +SixtyFour variant for people who were explorers to 
> try out the 64bit build.
> 
> 
> Because the GUI required the whole x11 infrastructure to run, and it was 
> pointed out that most people would not want to have to build that all 
> universal, I came up with a way to build the GUI separately. That way, it 
> could be 64bit only, and save the x11 stack from endless universal building.
> 
> 
> Things have changed; both basiliskii and sheepshaver have had their 64 bit 
> warts removed, and they do now work properly when built 64 (current 
> versions). There are several forks, and one of the forks now is better than 
> the upstream I used in 2017 I believe.
> 
> 
> Both basiliskii and sheepshaver continue to work very well. I still use 
> MacPort's 32 bit version all the time on my older 10.6 system, to run some 
> older MacOS9 software I like to use. It works just great, and I don't think 
> it ever needs to be updated, to be honest, although I have not rebuilt it in 
> a while to see if anything has changed in the build supporting ports.
> 
> 
> I recently downloaded a prebuilt version of both basiliskii and sheepshaver 
> from the 'macemulation' website that is 64bit and runs on BigSur, and that 
> works well too.
> 
> 
> I have not tried to update the basiliskii and sheepshaver ports in MacPorts 
> in recent years, although no doubt it could be done without too much trouble. 
> Newer versions I note are using xcode to build, and that adds a layer of 
> complexity, and makes builds on older systems harder.
> 
> 
> Perhaps the two ports might be retired, and people sent to upstream sources 
> to download prebuilt binaries instead. There are upstream versions available 
> that run as far back as 10.6.8 I believe.
> 
> 

Re: multi-ask

[Ken Cunningham]

When I last updated the basiliskii and sheepshaver ports I was still 
fairly new to macports and took them on as a challenge. They had some 
interesting wrinkles I was looking to understand.



At that time, both of them did not run well when built as 64-bit 
versions; the JIT code, that really makes them run quickly, did not work 
when built 64 bit, and the networking stack had not been fixed to build 
and run 64 bit. Of course, at that time, macOS supported i386, and we 
were (most of us) unaware that 32bit Intel support was about to disappear.



So the ports were set up to force both of them to build as 32bit 
versions, which worked. I allowed a +SixtyFour variant for people who 
were explorers to try out the 64bit build.



Because the GUI required the whole x11 infrastructure to run, and it was 
pointed out that most people would not want to have to build that all 
universal, I came up with a way to build the GUI separately. That way, 
it could be 64bit only, and save the x11 stack from endless universal 
building.



Things have changed; both basiliskii and sheepshaver have had their 64 
bit warts removed, and they do now work properly when built 64 (current 
versions). There are several forks, and one of the forks now is better 
than the upstream I used in 2017 I believe.



Both basiliskii and sheepshaver continue to work very well. I still use 
MacPort's 32 bit version all the time on my older 10.6 system, to run 
some older MacOS9 software I like to use. It works just great, and I 
don't think it ever needs to be updated, to be honest, although I have 
not rebuilt it in a while to see if anything has changed in the build 
supporting ports.



I recently downloaded a prebuilt version of both basiliskii and 
sheepshaver from the 'macemulation' website that is 64bit and runs on 
BigSur, and that works well too.



I have not tried to update the basiliskii and sheepshaver ports in 
MacPorts in recent years, although no doubt it could be done without too 
much trouble. Newer versions I note are using xcode to build, and that 
adds a layer of complexity, and makes builds on older systems harder.



Perhaps the two ports might be retired, and people sent to upstream 
sources to download prebuilt binaries instead. There are upstream 
versions available that run as far back as 10.6.8 I believe.

Re: multi-ask

[chilli.names...@gmail.com]

Interesting idea to attempt coax Mojave to build for 32-bit. However, I find 
when I stray from conventional installations to custom, even when I take 
detailed notes, over time I forget what I did, and it becomes an issue when 
recreating an installation. 

I'm not sure "need" is accurate, but I'd like to have basiliskii and 
sheepshaver to possibly support a personal journey with Apple 68k hardware. 
While qemu appears to be moving towards full 68k support, afaik the only way to 
emulate the old systems in qemu is with a binary alpha release, 
qemu-system-m68k. As soon as qemu supports mac 68k emulation in general 
release, and is available through macports, I can return to Mojave or Catalina, 
as Apple's ban on 32-bit shouldn't reach into emulator guests.

> On Nov 21, 2021, at 11:15, Ryan Schmidt  wrote:
> 
> On Nov 21, 2021, at 10:08, Chilli wrote:
> 
>> 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. 
> 
> With considerable effort, you may be able to build 32-bit software on Mojave. 
> The trick may have been to force MacPorts to use the 10.13 SDK, or it may 
> have involved installing the OS headers into /usr/include using the hidden 
> installer pkg. There is some information floating around somewhere in the 
> MacPorts archives about this. However MacPorts base wasn't designed to 
> accommodate 32-bit building on 10.14 so it may be more trouble than it's 
> worth. I myself stayed on High Sierra until recently to be able to continue 
> to build 32-bit software. However the inconvenience of the Let's Encrypt 
> former root certificate expiring has compelled me to leave 32-bit software 
> behind and upgrade my OS.
> 

Re: multi-ask

[Ryan Schmidt]

On Nov 21, 2021, at 10:08, Chilli wrote:

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

With considerable effort, you may be able to build 32-bit software on Mojave. 
The trick may have been to force MacPorts to use the 10.13 SDK, or it may have 
involved installing the OS headers into /usr/include using the hidden installer 
pkg. There is some information floating around somewhere in the MacPorts 
archives about this. However MacPorts base wasn't designed to accommodate 
32-bit building on 10.14 so it may be more trouble than it's worth. I myself 
stayed on High Sierra until recently to be able to continue to build 32-bit 
software. However the inconvenience of the Let's Encrypt former root 
certificate expiring has compelled me to leave 32-bit software behind and 
upgrade my OS.

Re: multi-ask

[chilli.names...@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  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:
>> 
>> advancemame3.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 
> pl

Re: multi-ask

[Ryan Schmidt]

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:
> 
> advancemame3.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 t

multi-ask

[chilli.names...@gmail.com]

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.


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:

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


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. 


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. 



Any replies, answers, explanations, criticisms and insults appreciated! 
Thanks for everything!

Kind Regards,
Chilli