BSD on a Mac Mini G4 - BSD
My latest project is to install BSD on an old Mac Mini G4 I pulled from the back of a closet.

First attempt was with NetBSD 9.0-macppc, but I found the instructions too confusing. I guess I'm not as hardcore as I used to be. ;-)

Second try was with FreeBSD 12.0 powerpc. That went well; the install program knew what to do with this hardware and it wasn't any more difficult than with an x86 or amd64 machine. Then ran portsnap to fetch and extract the ports tree. But when I tried to build the ksh93 port I discovered that 12.0 was already end-of-life'd and therefore the port system refused to build anything. Arghh, I wish they'd told me that sooner!

So back to the FreeBSD site and grab the ISO for 12.1 powerpc. So far so good. Installed, and currently building ksh93.

Does anyone else have experiences with BSD on this hardware they want to share?
Installing NetBSD is certainly an interesting task. It pays off too: Once it works, you don't want to replace it anymore because you don't want to ruin your hard work. Similar to what I had experienced with Gentoo ... :-)

Sadly, I never had a Mac G4, so I cannot contribute anything useful - at least this time.
I hit a snag building the dependencies for the ksh93 port on FreeBSD. The configure script for gmp-6.2.0 doesn't recognize the machine type 'powerpc7447-unknown". Many things have are going to have gmp as a dependency, so this kinda leaves me dead in the water.

Currently trying to build spectrwm and its dependencies, just to see if I hit a similar snag.

This is an old underpowered machine I wasn't using anyway, so if I can't bring it to a usable state it's no big deal. Not sure it's worth reporting the error to the maintainer of the gmp port.

Maybe I'll give OpenBSD-6.7-macppc a try next. ;-)

There's nothing like building a window manager and its dependencies from source on a slow machine -- even if the window manager is as simple as spectrwm -- to make you appreciate just how much software goes into a graphical environment.

Well this is encouraging. The build of spectrwm and *all* of its dependencies succeeded. "All" included stuff like python3.7. The only thing I had to do was remove the -Werror switch from the $CFLAGS used to compile spectrwm itself. (The warning emitted by the compiler looked fairly benign.)

Also, I was able to build mksh instead of ksh93. Cool, now I can use my preferred shell. Tomorrow I'll get to work building st and some of my favorite utilities. As long as I avoid things that need gmp this machine might be usable after all. (If that's the only problem, I *will* submit that bug report.)

fwiw, gmp is pulled in by anything depending on glib -- including the desktop-file-utils port, which is used by every file manager I've looked at, including my favorite vifm. God, I hate that glib crap! Fortunately I know I can build vifm without the desktop file stuff (I build it from github sources on my Linux boxes), so I'll do that here instead of using the port.

gmp is also a direct dependency of the gcc9 port, so any port that's still requiring that instead of clang to build is going to fail.
(25-05-2020, 05:16 PM)ckester Wrote: Also, I was able to build mksh instead of ksh93. Cool, now I can use my preferred shell.

Now I’m curious: Do you really notice a big difference between those?
I forgotten what it was, but several years ago when I was deciding between them there was a feature I needed that was in ksh93 but not mksh. I haven't done the comparison since then and wouldn't be surprised if by now they're feature-by-feature identical.
So you actually prefer a shell with less features? ;-)

AT&T (or what is left from their AST team) has shifted towards ksh2020 now, so I can only assume that the mksh will try to follow up again... in one of my tests, the mksh failed to run a ksh93 script once, and I haven't touched it since then.
No, when I referred to my "favorite shell" I meant Korn shell in general, as opposed to bash, zsh, or whatever. Sorry if that was unclear. I haven't tried ksh2020 yet, currently prefer ksh93, but will use mksh in a pinch (like the one I'm in now).
Returning to the problem after a good night's sleep, those dependencies seem odd for many of the ports affected. Why should gcc, for example, depend on a lib that's usually built with it?!? Sounds circular.

I'm going to play around with the knobs and see if I can work around that. (I'd been using the out-of-the-box settings and accepting default options.)
That’s why GCC has a bootstrap script on some platforms. Weird GNU stuff though.
My bad, FreeBSD is still using gcc rather than clang on this platform.

Members  |  Stats  |  Night Mode