Re: Building zsh/db/gdbm on MacOS Sequoia
"Daniel Shahaf" <[email protected]> Mon, 29 Jun 2026 17:41:58 +0000
| Newsgroups | gmane.comp.shells.zsh.devel |
|---|---|
| Message-ID | <[email protected]> |
Oliver Kiddle wrote on Mon, 29 Jun 2026 11:22 +00:00: > Bart Schaefer wrote: >> On Fri, Jun 26, 2026 at 7:56 PM Mikael Magnusson <[email protected]> wrote: >> > >> > Yeah, the asymmetry is that pcre has pcre-config, and gdbm doesn't >> > have that nor a pkgconfig file, so there's not really anything we >> > could do short of find -name libgdbm.so / > > Not long ago, I came across a library that used find like that below > /usr which had the effect of hanging the build on my system for a very > very long time. > > I don't think using the package manager as in the suggested patch is a > great idea either. There are way too many different ones. There can be > more than one on particular systems: you might have gdbm from > more than one of mac ports, conda, brew, pkgsrc, ravenports, etc > > Using pkg-config files or specific commands like pcre2-config is > well established and it is clearer how to control which is used where > there are multiple installations of the same library. The same goes for > assigning specific values to variables like LDFLAGS to direct the build > to needed libraries. We should be trying to make the configure script > simpler. FWIW, there's similar discussion about gdbm here: https://github.com/orgs/Homebrew/discussions/6810 "No pc file for gdbm?" The conclusion: > You can always ask upstream [= gdbm] to include [a pkg-config `.pc` file]. If gdbm upstream shipped a .pc file, the problem of compiling and linking against it would be solved once and for all. In our case, we could use PKG_CHECK_MODULES [1]. (I haven't checked what version of autoconf this macro was added in, but I don't imagine that'll be a problem.) This would work on all platforms (not just darwin) and package managers (not just macports). It's even agnostic of build system: if we were to switch away from autoconf one day, we wouldn't need to reimplement anything, but only to use the new build system's pkg-config integration. (= to translate the PKG_CHECK_MODULES invocation into the configuration language of the new build system] [1] https://autotools.info/pkgconfig/pkg_check_modules.html Separately, I've noticed patch replaces $LDFLAGS rather than prepend to it, as it does with $CPPFLAGS. That seems like it might be unintentional? Just pointing it out in case the patch is merged after all. Cheers, Daniel