Unofficial MacPorts 10.5 binary repo

[doctor_dog]

EDIT: I am running an unofficial Macports repo for 10.5 Leopard. This means you can install a subset of Leopard packages via Macports with zero compilation time. While not even close to every port is included (there are over 30,000 available via Macports), I've focused on big ticket items that take a lot of compilation time such as compilers and larger libraries.

For instructions on how to use, see this:

https://forums.macrumors.com/threads/unofficial-macports-10-5-binary-repo.2376248/post-31879173

_______________________________________________________________________________
TL;DR: Is there any legal obstacle or other hindrance to hosting a third-party MacPorts binary archive repo? Would the community find value in this or have I overlooked something basic?

___________________

After reading countless forum posts, MacPorts tickets, and random blogs trying to get new versions of programs to build, it seems to me a very helpful thing for the 10.5 PPC community would be avoiding building packages whenever possible. As expected for such old hardware, things seem to break easily for us when new versions of packages and deps get released. If a new version doesn’t work, just go grab the old one that built OK from the bin repo. This would also allow much quicker testing of programs without having to build from scratch every time (or handling your own local bin repos).

Creating bundled .pkg/.mpkg seems overkill for a community that is (ostensibly) already quite command-line savvy, I would like to stick with MacPorts as it is a great package manager and can build from source whenever a binary isn’t available. The only real information from MacPorts official I have found on the topic is this: https://trac.macports.org/wiki/Mirroring. However, this is geared toward hosting a full mirror of MP; I'm only proposing hosting 10.5 binaries which MP doesn't build for currently. Does anyone have any experience in this area as it relates to legality/permissibility? I can obviously email MP as well.

With that in mind, the goal for me is to have a functional public binary archive server for us 10.5 PPC folks (if I have more success building fat binaries on my Intel MBP, this could expand to 10.5 universal builds and/or Intel binaries). I have stood up a test binary archive server on my home LAN and it seems to work great among my three 10.5.8 machines. I have an unrelated public-facing web server that isn’t doing a whole lot right now; I would be fine hosting a public repo if that is legally and otherwise permissible and assuming it doesn’t get hammered with 100s of gigabytes of transfer requests (which I suppose could happen quite quickly via bots or some other trash, but I’ll handle that if the situation arises).

Before I get ahead of myself and re-purpose a web server, is this a good idea? Would the community find this valuable?

 

[pipetogrep]

I’ve been considering doing something like this at least for the most difficult packages like libgcc7 and gcc7.

 

[pipetogrep]

This looks like it could be pretty easy. It doesn't seem to rely on anything special. Just a simple web server with the directory structure that mirrors what it drops in the "/opt/local/var/macports/software" directory that contains the binaries. After that, the server URL needs to be added to "/opt/local/etc/macports/archive_sites.conf".

I'll try to have a server up in the next couple of weeks if you want to try testing it out @doctor_dog. I won't be able to host all buildable packages as I only have an upgraded dual G4 but I could make binaries of things like libgcc7, gcc7, git, the various pythons, and all the dependencies required for them. It takes me days to build it but after that, it should be a matter of the occasional upgrades and leaving the old beast running overnight then syncing the binaries to the web server.

 

[barracuda156]

Guys, please express your interest here: https://trac.macports.org/ticket/66288
Ryan said official buildbot is likely doable.

 

[barracuda156]

I’ve been considering doing something like this at least for the most difficult packages like libgcc7 and gcc7.

I would suggest gcc11, at least for Leopard and SL. gcc12 works, but has one annoying bug (Iain gonna fix it, but not yet in either master or Macports).

 

[barracuda156]

it seems to me a very helpful thing for the 10.5 PPC community would be avoiding building packages whenever possible. As expected for such old hardware, things seem to break easily for us when new versions of packages and deps get released. If a new version doesn’t work, just go grab the old one that built OK from the bin repo. This would also allow much quicker testing of programs without having to build from scratch every time (or handling your own local bin repos).

Creating bundled .pkg/.mpkg seems overkill for a community that is (ostensibly) already quite command-line savvy, I would like to stick with MacPorts as it is a great package manager and can build from source whenever a binary isn’t available. The only real information from MacPorts official I have found on the topic is this: https://trac.macports.org/wiki/Mirroring. However, this is geared toward hosting a full mirror of MP; I'm only proposing hosting 10.5 binaries which MP doesn't build for currently. Does anyone have any experience in this area as it relates to legality/permissibility? I can obviously email MP as well.

With that in mind, the goal for me is to have a functional public binary archive server for us 10.5 PPC folks (if I have more success building fat binaries on my Intel MBP, this could expand to 10.5 universal builds and/or Intel binaries). I have stood up a test binary archive server on my home LAN and it seems to work great among my three 10.5.8 machines. I have an unrelated public-facing web server that isn’t doing a whole lot right now; I would be fine hosting a public repo if that is legally and otherwise permissible and assuming it doesn’t get hammered with 100s of gigabytes of transfer requests (which I suppose could happen quite quickly via bots or some other trash, but I’ll handle that if the situation arises).

Before I get ahead of myself and re-purpose a web server, is this a good idea? Would the community find this valuable?

So, my thoughts:

1. It is worth writing in the ticket I referred above, so that Macports is aware that it is not only myself who cares about PPC, LOL. We really want an official buildbot and archive, since using a side one may create problems with tickets. (If we care about development and support – and honestly we should.)
2. From my side, I would like to encourage building ports from source, whenever hardware permits. (Yeah, getting mpich-gcc12 built from scratch on a single core G4 is a pain, I understand that.) Because that allows debugging, and we need people testing ports at least in terms of building.
3. Re universal: building as ppc+x86_64 is a lot of pain. I began doing that on 10.6.8 and quickly gave up, since a) that gonna require multiple PRs which will be hard to merge, since no one ever tried to build ports for such a combination; b) some essential ports are likely non-trivial to be fixed if not impossible (cases: Boost, new GCC, anything depending on these); c) there is little utility in that, TBH, it is easier to set up Macports to build for ppc via Rosetta (ppc64 is not supported anyway) – this is what I do myself.

 

[pipetogrep]

Guys, please express your interest here: https://trac.macports.org/ticket/66288
Ryan said official buildbot is likely doable.

I'll do so. Thanks.

 

[doctor_dog]

So, my thoughts:

1. It is worth writing in the ticket I referred above, so that Macports is aware that it is not only myself who cares about PPC, LOL. We really want an official buildbot and archive, since using a side one may create problems with tickets. (If we care about development and support – and honestly we should.)
2. From my side, I would like to encourage building ports from source, whenever hardware permits. (Yeah, getting mpich-gcc12 built from scratch on a single core G4 is a pain, I understand that.) Because that allows debugging, and we need people testing ports at least in terms of building.
3. Re universal: building as ppc+x86_64 is a lot of pain. I began doing that on 10.6.8 and quickly gave up, since a) that gonna require multiple PRs which will be hard to merge, since no one ever tried to build ports for such a combination; b) some essential ports are likely non-trivial to be fixed if not impossible (cases: Boost, new GCC, anything depending on these); c) there is little utility in that, TBH, it is easier to set up Macports to build for ppc via Rosetta (ppc64 is not supported anyway) – this is what I do myself.

Thanks for the suggestions, you have sound points. My $0.02:

1.) Will do, makes sense.
2.) Assuming we don't get a buildbot from MP official in the short term, I was envisioning this more from a "don't spend 3 days bootstrapping a fresh Leopard install if you don't have to". I don't much care for time machine on these old Macs (maybe if I get a proper Firewire 800 SATA encolsure that might change), so that is why I created my own bin archive repo to share amongst my machines originally. Ethernet is still the fastest interface I believe a PPC-based laptop can have (I don't have any PPC desktop form factors) and migration assistant over Ethernet has been inconsistent for me. I understand your concern though; maybe we limit the available binaries to fairly stable libraries or other things that don't get updated all that often? Or maybe there's a better solution that I'm not thinking of?
3.) I discovered this as well and completely agree. My +universal variants stopped being viable quickly for any package with non-trivial deps (e.g. anything requiring gcc7). Most of the packages in my repo are ppc32. I have started to build a handful of x86_64 binaries for my '07 MBP and included those as well. Not many, but they do exist. That's my path forward if this project continues, just have separate binaries for both archs.

All that being said, I did end up pushing my repo public and it appears to be working. Assuming it's OK, I will share the public key here in the next day or so and whomever would like to help test is more than welcome to. It might be a short-lived project if MP official gets a PPC buildbot. That's a huge win if we can get that to happen though, so I will gladly kill my unofficial repo when that day comes.

@pipetogrep if you also have your server coming online soon we could perhaps sync binaries from one another, effectively creating a redundant mirror that could load-balance traffic with some simple DNS hacks or something. Just a thought.

As always, thanks to everyone for their contributions and help. This community is awesome =)

 

[barracuda156]

3.) I discovered this as well and completely agree. My +universal variants stopped being viable quickly for any package with non-trivial deps (e.g. anything requiring gcc7). Most of the packages in my repo are ppc32. I have started to build a handful of x86_64 binaries for my '07 MBP and included those as well. Not many, but they do exist. That's my path forward if this project continues, just have separate binaries for both archs.

Okay, the issue with non-Apple GCC is that it needs driver-driver in order for multiple archflags to be passed. There is a discussion here: https://github.com/iains/darwin-toolchains-start-here/discussions/13
If this is fixed, then building universal ports becomes far easier, at least within either PPC or Intel (not sure about a mix).

Until then, the only working solution is to use muniversal PortGroup. In fact, any port requiring C/C++11 and higher or blacklisting *gcc-4.* must include muniversal 1.0 or muniversal 1.1 in order to build as +universal with GCC. Since on PPC we only have GCC, this becomes the only solution.

Now, the problem is that a) there are no plans AFAIK to add this into the base, so we need to manually make PRs for each port, and there are literally thousands; b) using muniversal is often as easy as adding a single line in the portfile, but not always, and in some cases it is completely non-trivial (see gcc10-bootstrap as an example, and it took months to fix that properly), so it cannot be done automatically; c) every case requires testing, since it may still fail, or may fail with one version of the PG but not the other, or may require manual trickery.

In result, this will not be done in general, ever: no one has time – or desire. It is also a better investment of time to fix driver-driver, and submit that to GCC upstream.
Of course, in the meanwhile some ports, especially important ones, can be fixed for +universal via muniversal PG. See examples, it is used in many ports.

 

[doctor_dog]

How to Use Unofficial MacPorts 10.5 Binary Archive Repo

IMPORTANT: Use these at your own risk! This is the obligatory "I take no responsibility for the use of this repo, what you do with it, or its contents". There is no warranty of any kind, implied or express. I didn't write the code for any of these packages and I cannot guarantee what is in them is secure! If you want to manually do a code review before installing a package, then by all means (you likely want to build from source anyway!). I have built all of these packages myself from source via MacPorts. These packages were all built for 10.5 and may not function on other OS X targets. YMMV.

There are three main steps required to tap into the repo. Doing these steps should effectively give you access to pre-built MP packages from my repo if I have it, else MP will simply build the port from source as "normal". Most packages are for PPC, there are some universal, and even fewer Intel packages.

Steps to enable:

1.) Uncomment the last line of the $prefix/etc/macports/archive_sites.conf (the one that says "name macports_archives") and add a section as follows:

name Private_MP_Archive urls http://143.198.135.172:80/ type tbz2

Note that the server URL of my repo is http://143.198.135.172. I do not have an extra domain and third-party SSL cert lying around, so I am using good ol fashioned http for now.

2.) Download the public key and enable MP to use it. You have to do this, or else MP won't trust the signature on my packages and will refuse to install.

-Download the public key from the repo: http://143.198.135.172/mp.binarchive.pub
-Copy it to somewhere useful (I'm using /opt/local/share/macports in this example).
-Edit $prefix/etc/macports/pubkeys.conf and add a line to reference the key. For me, this looks something like this:
# MacPorts system-wide public key configuration file. # Downloaded archives will only be used if they can be verified by one # of the public keys listed here. Use absolute paths, one per line. /opt/local/share/macports/macports-pubkey.pem /opt/local/share/macports/mp.binarchive.pub

Note: do NOT get rid of the macports-pubkey.pem line if you want MP to continue to function as expected. There is no harm in leaving it there.

3.) Note: This step is optional, but in my opinion provides the best UX without having to specify extra command line options when installing packages (see tips below for what I mean).

Uncomment and edit /opt/local/etc/macports/macports.conf so that "buildfromsource" is set to "ifneeded". It starts on line 41 for me and should look something like this when you're done editing:
# When MacPorts should build ports from source. # - ifneeded: Download binary archives if available; build from source # otherwise. # - always: Always build from source; never try fetching archives. # - never: Never build from source; try fetching archives and abort if # unavailable. buildfromsource ifneeded

4.) Enjoy your new binary package life without building every single package from source =)

At this point, I have tested the repo with my own machines and everything seems to work as intended. If you come across an issue, please send me a DM. I consider the project to be in Alpha status (e.g., no SLAs, there might be corrupt packages I don't know about, something might not have been signed properly, etc.). Once we get a few folks testing it semi-regularly I would feel comfortable upgrading to Beta status. Unless MP decides against building for 10.5 PPC and there is a ton of interest, this probably will stay in Beta for the foreseeable future. When I have a little more time, I will write a cron job to push nightly updates from my build boxes to the repo, TBA. Until then, I will update the repo whenever reasonable.

Tips on Usage:

• Use the "-b" option to get MacPorts to only install a port if there is a binary available. It won't try to build from source if you use this.

Example: "sudo port -b -v install foo"

• Use the "-n" option to get Macports to ignore new versions of dependencies. This is useful if you've recently run a port selfupdate and then try to build a package that has a lot of dependencies that need updating. -n will tell Macports to ignore old versions of those dependencies and use them as-is. Be careful with this one, should probably only be used if you know what you're doing, but can be useful if a new dep won't build for whatever reason.

Example: "sudo port -b -v -n install foo" will only install a package if the binary is available and ignore new versions of foo's deps (assuming the old versions are installed)

• A bin archive repo is just a copy of the $prefix/var/macports/software folder (with signature files added). If you want to check what packages are available, simply hit the root of the web server (i.e., http://143.198.135.172/).
• I think the obviously useful packages are the compilers and libraries, but you tell me!

Misc. notes:

1. This is not an exhaustive collection of available ports, only ones that I have built for various reasons over the past few months.
2. This won't be updated on a regular basis unless there is a sharp uptick in utilization. This should be fine for fairly "static" packages that don't receive updates all that often, but is probably not ideal for packages under active development.
3. I am open to archive submissions for ports that are either outdated or don't exist in my repo. Send me a DM please.

I hope this is useful to folks, curious to see what kind of traction there is. As previously stated, the real goal is to petition MP to start building for 10.5 PPC again and make this project obsolete, but until then I will run it as long as it makes sense to. Enjoy!

P.S. I wrote this up using the fresh copy of Arctic Fox from @wicknix; thank you! Big thanks as well as to @barracuda156 for the continued work on these old beasts of machines! Viva la PPC!

 

[barracuda156]

It may be worth adding 10.6 PPC packages (possibly even Rosetta ones), because this is one thing Macports is unlikely to ever get (some folks there do not like it, and I am the only contributor testing it and working on it).
Some will need to be built from custom portfiles, but such are rather few. Importantly, GCC needs additional patch on 10.6 PPC.

 

[doctor_dog]

For those interested, I've updated my unofficial Macports repo to the latest versions without too much fiddling or Portfile surgery. Looks like there's a new port, gklib, that didn't exist in my old port tree. It builds fine with minimal config.

The exceptions that fail to build are:

libsdl2 - I think this is a known offender at this point, I'm stuck on 2.0.6.
metis - New version fails to build. I don't have a need for the latest greatest, but if you do it might be worth a MP ticket. The latest update builds fine (03/06/23).
nano - I'm still using 5.0 and I don't have any compelling reason to upgrade to the latest (7.2) so I left it alone.

Cheers!

 

[doctor_dog]

It may be worth adding 10.6 PPC packages (possibly even Rosetta ones), because this is one thing Macports is unlikely to ever get (some folks there do not like it, and I am the only contributor testing it and working on it).
Some will need to be built from custom portfiles, but such are rather few. Importantly, GCC needs additional patch on 10.6 PPC.

I'm open to this, but I don't have any machines with the DP installed at the moment. I'm fairly set on 10.5 for stability and feature set, but if you want I'm happy to give you upload credentials to the repo if you want to put 10.6 packages up. If/when Macports official starts building for 10.5 again I will probably turn this into a Tiger/10.6 PPC repo anyhow.

 

[Rikintosh]

TL;DR: Is there any legal obstacle or other hindrance to hosting a third-party MacPorts binary archive repo? Would the community find value in this or have I overlooked something basic?

___________________

After reading countless forum posts, MacPorts tickets, and random blogs trying to get new versions of programs to build, it seems to me a very helpful thing for the 10.5 PPC community would be avoiding building packages whenever possible. As expected for such old hardware, things seem to break easily for us when new versions of packages and deps get released. If a new version doesn’t work, just go grab the old one that built OK from the bin repo. This would also allow much quicker testing of programs without having to build from scratch every time (or handling your own local bin repos).

Creating bundled .pkg/.mpkg seems overkill for a community that is (ostensibly) already quite command-line savvy, I would like to stick with MacPorts as it is a great package manager and can build from source whenever a binary isn’t available. The only real information from MacPorts official I have found on the topic is this: https://trac.macports.org/wiki/Mirroring. However, this is geared toward hosting a full mirror of MP; I'm only proposing hosting 10.5 binaries which MP doesn't build for currently. Does anyone have any experience in this area as it relates to legality/permissibility? I can obviously email MP as well.

With that in mind, the goal for me is to have a functional public binary archive server for us 10.5 PPC folks (if I have more success building fat binaries on my Intel MBP, this could expand to 10.5 universal builds and/or Intel binaries). I have stood up a test binary archive server on my home LAN and it seems to work great among my three 10.5.8 machines. I have an unrelated public-facing web server that isn’t doing a whole lot right now; I would be fine hosting a public repo if that is legally and otherwise permissible and assuming it doesn’t get hammered with 100s of gigabytes of transfer requests (which I suppose could happen quite quickly via bots or some other trash, but I’ll handle that if the situation arises).

Before I get ahead of myself and re-purpose a web server, is this a good idea? Would the community find this valuable?

something I hate about programming (especially opensource), with all the strength in my body, is the fact that they constantly change keywords, you try to compile something, then every compilation fails because someone changed the call term " compile_that_thing" to "com_t_thing" or something stupid like that. "The call compile_that_thing is deprecated" Every few months, some idiot changes a term, and it makes compiling work tedious.

I spent nights awake for several weeks trying to compile a fork of eduke32 that would work with ionfury, it was extremely frustrating

 

[dysmas]

Hello will this work with tiger?

 

[barracuda156]

Hello will this work with tiger?

I guess someone has to step in to maintain or at least submit some ports for Tiger. Anyone?

 

[doctor_dog]

Hello will this work with tiger?

As-is, no. You could potentially do some Macports surgery, manually download the binary archives and rename them, but it would not be scalable or recommended (and it might not even work). There's an effort to get Macports official to start building for Leopard again, and if that happens I will change my repo to be an unofficial Tiger (and likely also 10.6 PPC) one instead. If there is enough interest in the meantime, I will consider carving out some time to install Tiger on one of my machines and spend a few weeks building all the packages. It's been quite busy on the home front as of late.

If you need pre-compiled binaries the current best option in my observation is to use the tiger.sh package manager (or look for the program you want in mac garden, etc).

EDIT: I see you just came from that thread. I agree w/Baracuda you probably don't want macports to "think" that the package was installed via macports. However, if you're talking about libraries etc. that macports needs to build other packages, you should be able to pass the necessary flags inside of macports to point to those packages external e.g., from tiger.sh.

 

[barracuda156]

EDIT: I see you just came from that thread. I agree w/Baracuda you probably don't want macports to "think" that the package was installed via macports. However, if you're talking about libraries etc. that macports needs to build other packages, you should be able to pass the necessary flags inside of macports to point to those packages external e.g., from tiger.sh.

Re linking to libs: that might work, but a) may not be a trivial task, b) as a consequence, likely to result in a mess and unlikely to save much time if any, and c) if such scenario, one doing this won’t get any help, in Macports or elsewhere, since the environment gonna be non-reproducible and no one gonna debug builds against libraries of unknown origin.

P. S. To be honest, I don’t really get what’s the big deal to build ports. Well, okay, GCC may be a pain on a slow G4, if that is the only issue, we can solve that. One perhaps doesn’t really need MPICH on a slow machine, and everything else builds reasonably fast.

 

[doctor_dog]

Re linking to libs: that might work, but a) may not be a trivial task, b) as a consequence, likely to result in a mess and unlikely to save much time if any, and c) if such scenario, one doing this won’t get any help, in Macports or elsewhere, since the environment gonna be non-reproducible and no one gonna debug builds against libraries of unknown origin.

P. S. To be honest, I don’t really get what’s the big deal to build ports. Well, okay, GCC may be a pain on a slow G4, if that is the only issue, we can solve that. One perhaps doesn’t really need MPICH on a slow machine, and everything else builds reasonably fast.

Ah, ok. I don't have the insight into the ramifications of what happens if you do this (never personally tried it with MP). My only point is if you absolutely must have some piece of software it *might be possible but you'll be on your own to fix it. Sounds like more trouble than its worth.

 

[barracuda156]

Ah, ok. I don't have the insight into the ramifications of what happens if you do this (never personally tried it with MP). My only point is if you absolutely must have some piece of software it *might be possible but you'll be on your own to fix it. Sounds like more trouble than its worth.

Well, it might, but is it worth screwing everything up for the sake of saving several hours of compilation time? Perhaps the only sensible scenario is if one needs to build a specific piece of software once, nothing else and no further updates. Then yes, and perhaps link it statically.

 

[doctor_dog]

Quick update, I upgraded all packages to latest as of this evening and put fresh ports up on the archive server. It's up to 537 packages now (list attached), more than I would have guessed. I'll try to update this more frequently going forward. If there's a port you want that's not on here send me a DM and I'll give it a go.

 

[barracuda156]

Quick update, I upgraded all packages to latest as of this evening and put fresh ports up on the archive server. It's up to 537 packages now (list attached), more than I would have guessed. I'll try to update this more frequently going forward. If there's a port you want that's not on here send me a DM and I'll give it a go.

You will want boost181, since a number of PPC-relevant bugs we fixed in it (in fact serious ones). Macports still defaults to boost176, but some ports override that, requiring a newer version.

gcc10-bootstrap is at 10.4.0 now.
gcc11 is at 11.4.0.

P. S. By the way, when building libgccX, what settings did you use? By default, presently, Macports uses libgcc7 as the runtime on 10.4–10.5, and libgcc12 as the runtime on 10.6+. Unless these defaults are modified, libgcc11 may not be built correctly, and then gcc11 will not be usable.

If resulting compiler is supposed to be used outside of Macports, it may make better sense to build it outside of Macports. On 10.5.8 you will need to build gcc10 first, and then use it to build whatever newer gcc you choose. gcc10 builds with Xcode 3.1.4 toolchain. Notice, in this case there is no separate libgcc, so you do not need to build gcc twice, like you would need in Macports.

 

[doctor_dog]

You will want boost181, since a number of PPC-relevant bugs we fixed in it (in fact serious ones). Macports still defaults to boost176, but some ports override that, requiring a newer version.

Thanks, I added Boost181 to the repo (http://hairypotter.org/boost181/).

And yes, I remembered I had an old domain name lying around collecting dust and yes it is ridiculous =) I kind of like it for the project though, eh? PPC is a bit of a hairy business these days, and we are potting digital seeds to blossom into the future. Right? Or maybe it's just total rubish. Either way, hairypotter.org is now the proud host of this project LOL.

gcc10-bootstrap is at 10.4.0 now.
gcc11 is at 11.4.0.

Gcc10-boostrap 10.4.0 is live on the repo already (http://hairypotter.org/gcc10-bootstrap/), but I have not gotten around to building updated gcc11.

P. S. By the way, when building libgccX, what settings did you use? By default, presently, Macports uses libgcc7 as the runtime on 10.4–10.5, and libgcc12 as the runtime on 10.6+. Unless these defaults are modified, libgcc11 may not be built correctly, and then gcc11 will not be usable.

I saw something about this either here or on Macport Trac a while back so decided to keep two separate install bases: gcc7 on my iBook and gcc11 on the Powerbook. I use the iBook as my buildbox so everything in the repo should be against gcc7 and libgcc7 (except [lib]gcc11 port). There was a small amount of time before I realized this was an issue where libgcc7 was coexisting with libgcc11 on the Powerbok...I don't know if that messed things up or not to be honest. I haven't noticed any problems, but then again I don't use all the software all the time.

If resulting compiler is supposed to be used outside of Macports, it may make better sense to build it outside of Macports. On 10.5.8 you will need to build gcc10 first, and then use it to build whatever newer gcc you choose. gcc10 builds with Xcode 3.1.4 toolchain. Notice, in this case there is no separate libgcc, so you do not need to build gcc twice, like you would need in Macports.

That's good to know. I lean on leopard.sh for gcc10 if I need to do something outside MP, though I try to keep everything MP for simplicity.

Will let you know if I have problems with boost181.

 

[headlessmike]

As someone who's spent weeks compiling MacPorts packages on my PowerBook G4, I'll have to try this out!

One package I've been struggling with is py311-matplotlib. Have you tried that package (or any other recent version of matplotlib) @doctor_dog?

 

[barracuda156]

As someone who's spent weeks compiling MacPorts packages on my PowerBook G4, I'll have to try this out!

One package I've been struggling with is py311-matplotlib. Have you tried that package (or any other recent version of matplotlib) @doctor_dog?

I can tell you it is broken

#67491 (py-matplotlib fails to build with gcc: cc1obj: error: '-Werror=unguarded-availability': no option '-Wunguarded-availability') – MacPorts

trac.macports.org

Had no time to fix it. Will try, keep poking me or Trac ticket.