3.8 KiB
+++
title = "More Pkgsrc"
date = 2020-07-14
[taxonomies]
tags = ["NonGNU","Packages","Pkgsrc"]
+++
While attempting to build the Thunar file manager (via pkgsrc) I encountered a
couple of other errors when it pulled in Samba4 as a dependency. Samba4 has
switched from using GNU autotools to it's own internal version of waf, a Python
based tool for configuring software. Waf takes most options that one
might pass to a GNU configure script. The difference is that an autotools
configure script will generally either ignore an option that it doesn't recognize
or else complain about it but still continue running. In the case of waf, an
unknown option causes an error, which aborts the build. In the case of samba4
this was --gmp-include.
About an hour later after failing to find where that option was being included from, in desperation I just did a grep through every Makefile in pkgsrc for "gmp-include" and found a few candidates. After temporarily commenting out the CONFIGURE_ARGS+= lines in devel/gmp/builtin.mk the samba4 build was up and running again. Note that I'm still unsure where it's getting pulled in, as I traced the Makefile includes through a few levels before giving up.
So, samba4 was building, then it wasn't again. This time the build failed due to the lack of the rpcgen utility, which is included in NetBSD (and indeed FreeBSD and OpenBSD and pretty much every BSD variant) but not in Linux. Linux has libtirpc and rpcgen is widely considered obsolete, and in fact was abandoned by it's chief developers, Sun, some time ago. However since we're building using pkgsrc it's assumed to be on our system. What's more frustrating is that there is no package for it in pkgsrc. This has already been noted on the mailing list as it causes more than one package build failure on Linux.
As it looks like going with pkgsrc is going to expect us to have rpcgen in several places, I set about trying to find a portable version of the source code. This turned out to be quite more of a chore than expected, but I did find an older version that had been pulled into a more or less portable state. I've imported that source into the HitchHiker build tree and rewrote the Makefile to suit our purposes. After adding it to our system and restarting the samba4 build (with "--gmp-include" still temporarily excised) samba4 builds successfully, and Thunar was able to build successfully as well.
This whole exercise is a good illustration of the challenges in making any software project truly portable, and why a more efficient build can be achieved by ignoring other systems and targeting the build only to the system actually in use. It's why I've imported the sources for ee, mksh and now rpcgen directly into the source tree and we're building them without any configure checks, as it's already known exactly what's on our running system.
Another thing this illustrates is some of the problems that arise due to projects switching their build system to one of the dozens of projects that have sprung up to "replace" GNU autotools. The fact is that very few, if any, of the replacements have achieved anything close to the flexibility and maturity of autotools and most probably never will. I'm not a fan of autotools by any means. It's a quagmire that most people don't understand; a lot of devs simply cut and paste from other projects and hope for the best. The Makefiles it generates are of a complexity and length that are ridiculous. However, the fragmentation that is currently occuring as some projects use cmake, waf, ninja, meson, jigdo, scons or whatever the next kid on the block is named is a true nightmare for anyone trying to build and maintain a full distro. That's not even accounting for the various homebrewed shell scripts that I encounter which have varying levels of POSIX compliance and make their own assumptions about the utilities present on your system.