Marc, Thank you for such a quick response.
On Wed, Apr 15, 2020 at 2:17 AM Marc Espie <es...@nerim.net> wrote: > > On Tue, Apr 14, 2020 at 10:02:06PM -0700, Paul Hardy wrote: > > Version 2.0 of my Unibetacode package is also under > > http://unifoundry.com/pub/unibetacode but it won't build on OpenBSD > > 6.6 because (among other reasons) the latest version of libtool > > available through pkg_add is older than what the latest version of > > autoconf requires, but that is another issue. > > Do you actually require gnu libtool ?... > > One reason it's not been updated is because we have our own in the base > system... you may wish to patch this away. I might decide to just create static libraries and remove libtool altogether. GNU libtool was created with the intention of being a portable way to create shared libraries across many systems, so that developers could invoke "libtool" and it would look the same way to developers across distros and produce consistent results across as many platforms as possible. It is inevitable that if one distribution has its own utility for creating shared libraries and also calls it libtool, there are going to be requirement conflicts. Apple also has their own version of libtool, and it doesn't even support the GNU "--version" tag. In spite of that, version 2.0 of my package builds just fine on macOS; "./configure", "make", "make check", and "make distcheck" all succeed. With what's available "out of the box" on OpenBSD 6.6, one conflict is that the latest version of autoconf available with pkg_add insists upon the latest version of GNU libtool, which is newer than the latest libtool version available through pkg_add. However, GNU libtool hasn't had a formal release in five years now. So there isn't an obvious best solution, except maybe for just creating a static library with ar and ranlib given my goal of portability across multiple distros. Earlier versions of Unibetacode didn't create a library, so I'm just now having to consider the best path forward for a portable library package. I also understand the position of OpenBSD in discouraging use of GNU Autotools. Stripping Autotools out of the package isn't my first choice but it may come to that. Thanks again, Paul Hardy