http://www.netbsd.org/~nia/tigersrc/

Unix software from pkgsrc for Mac OS X 10.4 (PowerPC Tiger)

Introduction

PowerPC Macs were produced in huge numbers, and a lot of this
hardware is still viable for use today, with professional software
such as Photoshop CS2 and Propellerheads Reason. They're still good
workstations, with lots of productivity software, and no
always-online tracking or distractions. Originally, I got mine for
running NetBSD, but found the pull of 20 year old commercial software
too tempting to resist.

Regardless, how usable is Mac OS X 10.4 for Unix professionals,
software developers, and command-line junkies? A surprising amount of
free software can still run, often with some simple adjustments. The
pkgsrc framework offers a platform-netural repository with powerful
frameworks that allow wide porting of software.

Pre-built PowerPC binaries for popular software are available,
including PostgreSQL, ImageMagick, Python 3, Wget, cURL, FFmpeg,
OpenSSH, OpenSSL, Apache Web Server, nginx, yt-dlp, SDL, Midnight
Commander, and many more.

Note: I make no guarantees about the security or up-to-dateness of
these packages, though I pinky promise they're better than what Tiger
includes by default. No warranty. Your fridge may explode. You may
find you're suddenly able to connect to servers that use modern
encryption, with all the risks that entails.

How to install software

Bootstrapping

Download the bootstrap kit

Extract the bootstrap kit on 10.4, set your PATH:


$ sudo tar -C / -xzpvf bootstrap-tiger.tar.gz
$ export PATH=/usr/pkg/sbin:/usr/pkg/bin:$PATH
$ export PKG_PATH=https://ftp.NetBSD.org/pub/pkgsrc/misc/nia/tigersrc/packages/All/


Add the last two lines to ~/.bash_profile.

Installing packages

Browse the repository


$ sudo pkg_add ffmpeg2


Challenges building modern software on 10.4

Part of this project is just for fun. Since I'm a developer
specialized in build systems, I get enjoyment out of pushing pkgsrc
as far as possible. Therefore, others should get to learn from this
too.

Refer to the mk.conf used for this repository, containing some
non-upstreamed workarounds, and the allowlist of packages.

  * Compiler: XCode's GCC 4.0 does not support C++11 or C11. Some
    software expects the compiler to default to C99, and does not
    explicitly specify -std=c99 in CFLAGS. This older version of GCC
    supports C99 but does not default to it, which should be worked
    around by setting FORCE_C_STD in pkgsrc. Many pieces of modern
    software like to specify lots of unsupported -W and -Wno
    arguments to customize warnings. These can be stripped out with
    pkgsrc's BUILDLINK_TRANSFORM.
  * Linker: The strict Mach-O linker included in Tiger is quite
    different from what modern software expects (e.g. it does not
    support -shared), unless that software uses libtool to make
    shared libraries in a portable manner. pkgsrc has long had a
    policy of "libtoolization", patching software that builds with
    plain Makefiles to use libtool. BUILDLINK_TRANSFORM can also
    translate many GNU ELF-style linker arguments to be compatible
    with the Darwin linker. I also found the -m option (for making
    multiply-defined symbols into a warning instead of an error)
    useful.
  * Library: Now-ubiqitious functions are missing, including
    clock_gettime and strnlen. These can easily be substituted from
    either libnbcompat or macports-legacy-support.
  * Atomics: Some wide atomic instructions are missing from 32-bit
    PowerPC. This isn't a PowerPC or Darwin-specific problem, since
    it affects other 32-bit instruction sets like i486.
  * Rust: Even if it worked on this platform, build times would be
    completely unacceptable. We use the pre-Rust versions of software
    like py-cryptography, since pkgsrc makes this easy. Reduce CO2
    emissions, keep writing C.
  * Locales: Certain UTF-8 file names fail to extract with bsdtar,
    with the UTF-8 sequences being detected as invalid. I haven't
    done much research into this yet, but it affects very few
    packages, such as the Icelandic aspell dictionary. This is
    probably not a bsdtar problem, since it works on NetBSD with the
    same tar version.
  * Toolchain bugs: There is a problem with signal.h that causes some
    software to fail to compile. This can be easily worked around by
    disabling the relevant type definitions by pre-defining macros in
    CFLAGS.
  * Kernel bugs: Sadly, kqueue does not work properly on Tiger.
    kqueue support is nearly always optional in software, but
    sometimes the detection needs to be turned off for this OS
    version. GNU configure makes this easy, other build systems may
    vary.
  * Other curiosities: The default dashboard widgets and screensaver
    in 10.4 use a surprising amount of CPU time that could be better
    spent on GCC. They're easy to disable, though.

Most of these problems are very general, so there's a lot of benefit
to be gained from automatically making these adjustments for
everything.

A big problem for this project is the wider ecosystem (well, mostly
GNOME-adjacent libraries) moving away from the GNU build system,
which mostly solved the problem of building shared libraries on
different platforms years ago, as well as nicely handling feature
detection. More work needs to be done before CMake and Meson can work
well on this platform, but also a way to say to them "yes, this OS
has this feature, but please ignore it" would be very useful (also
for testing!).

Related to the issue of 64-bit atomics is the world moving away from
32-bit platforms. If you're a stranger to the embedded world, this is
happening more slowly than you might think. While Mac OS X suffers
from the Year 2038 Problem, NetBSD solved it years ago. 64-bit wide
atomic instructions are unavailable on many NetBSD ports, with
libatomic being a hacky workaround at best.

Most importantly, if you maintain a C/C++ software project, and don't
specify -std=(gnu|c)XX in your build sytem already, please do. Keep
in mind that -Werror will fall over the moment you try building with
a compiler version that you haven't tested personally, and
distribution maintainers will want to disable it. For pkgsrc on
modern platforms, at any one time we're building with around 4
different major versions of GCC plus Clang, so we'd disable it even
if we weren't supporting crusty old stuff.

See also

  * MacPorts - lots of prior art
  * TigerBrew - lots of frozen packages to prevent them breaking,
    pkgsrc being more "live"
  * Macintosh Repository - useful for obtaining XCode

nia from the domain pkgsrc.org
Best viewed in Links.
Last updated March 2024.

Valid HTML 4.01 Strict