With the lead up to the release of pkgsrc-2019Q2 I picked up the ball with the testing on OS X Tiger again. It takes about a month for a G4 Mac Mini to attempt a bulk build of the entire pkgsrc tree with compilers usually taking up most days without success. To reduce the turnaround time, I switched to attempting a small subset of packages for a quicker turnaround using
meta-pkgs/bulk-large. After a couple of days of compiling I received a report in my mailbox showing breakages in key packages such as OpenSSL and libxml2.
security/openssl issue was a regression upstream which was resolved by bringing the packages up to date.
textproc/libxml2 breakage was due to
-Wno-array-bounds being passed to the compiler and the ancient version of GCC in Tiger not supporting it, resulting in a hard
cc1: error: unrecognized command line option "-Wno-array-bounds" error. The use of
BUILDLINK_TRANSFORM.Darwin here allowed the option to be removed dynamically, on the fly, confined to only being applied during builds on Darwin.
security/libgpg-error needed the definition of
__DARWIN_UNIX03 to make use of
unsetenv(3) which returns an integer,
unsetenv is called inside an
if statement and is unable to test the result as Tiger still used the old implementation by default, which returns
void. This results in the error
sysutils.c:178: error: void value not ignored as it ought to be when building. The fix for this came from macports.
There was many breakages due to the lack of support of
strnlen(3) in Tiger, Apple introduced support for this function in Lion, as a workaround,
pkgtools/libnbcompat now includes an implementation which will be used in place for packages which specify
strnlen as a requirement using
USE_FEATURES and the OS is marked as missing the features using
databases/sqlite3 has issues with readline included with Tiger, as a workaround locally, I switched to using gnu readline.
find(1) in Tiger lacks support for the
+ parameter for
-exec, the ability to install Python egg modules is currently broken, I worked around this locally to progress with the bulk build. Next step possibly is to make pkgsrc aware of
find as a tool and substitute legacy versions with a version from
GEN src/ast/parser.cc /usr/bin/bison: option `--defines' doesn't allow an argument Usage: /usr/bin/bison [-dhklntvyV] [-b file-prefix] [-o outfile] [-p name-prefix] [--debug] [--defines] [--fixed-output-files] [--no-lines] [--verbose] [--version] [--help] [--yacc] [--no-parser] [--token-table] [--file-prefix=prefix] [--name-prefix=prefix] [--output=outfile] grammar-file
Making use of the version in pkgsrc instead resolved the issue by specifying
With the advancement of language development and new standards being defined, pkgsrc grew support for specifying which versions of C & C++ language standards a package may require e.g
c++03. This in turn passes the relevant standard to the compiler using
--std= option. If the compiler being used doesn’t support the standard specified all tests in GNU
configure to determine the compiler and language support will fail, resulting in a cryptic
configure: error: C++ preprocessor "/lib/cpp" fails sanity check (
cpp is in
/usr/bin on Tiger). As a local workaround I have commented out the block in
pkgsrc/mk/compiler.mk so that the standard is not set. Not sure whether a knob to ignore setting the stand standard is worth it or to move forward by enforcing the use of a new (external) toolchain.
Next step is to address support for
find in the pkgsrc tools infrastructure, remove setting 64bit mode on G5 macs as a bootstrap mode as Tiger really doesn’t support it.
A glimpse of sevan.mit.edu as it runs currently: