(Splitting this reply in 2 mails; one regarding the libbsd bug, the other dedicated to discussing the observations made in the parent message). On 22/07/03 07:50PM, David H. Gutteridge wrote: > > If there are regressions with 0.11.6 vs. 0.11.5 (etc.), those should > really be reported back upstream (regardless of what we'd do). > And we have a culprit. The bug was introduced indeed between 0.11.3 and 0.11.4 [1]. In particular, this added chunk of code in the `install-exec-hook' target of the Makefile.am: ``` + if NEED_TRANSPARENT_LIBMD + # The "GNU ld script" magic is required so that GNU ldconfig does not complain + # about an unknown format file. + soname=`readlink $(DESTDIR)$(libdir)/libbsd.so`; \ + $(RM) $(DESTDIR)$(libdir)/libbsd.so; \ + (echo '/* GNU ld script'; \ + echo ' * The MD5 functions are provided by the libmd library. */'; \ + cat format.ld; \ + echo "GROUP($(runtimelibdir)/$$soname AS_NEEDED($(MD5_LIBS)))"; \ + )>$(DESTDIR)$(libdir)/libbsd.so ``` Results in having the target shared objects of @libbsd.so (the libbsd.so.0.11.6 shared lib) overwritten with the content echoed in quotes, whenever $(RM) is undefined or null and @libbsd.so isn't consequently preemptively removed. This leads to a circular reference between the @libbsd.so the libbsd library file, whereby the latter itself points to a non-existing object. And this accounts for the hangings witnessed while trying to link against libbsd. By skimming through the DESTDIR, I had noticed that libbsd.so.0.11.6 curiously consisted of a plain text file, but I couldn't make up my mind about it. It was @RVP, in a private mail exchange, to point me to where the problem actually lied. The reason why this happens on pkgsrc, whereas nobody else reported it in the Linux ecosystem, is that GNU Make defines RM among its implicit variables [2] and aliases it to `rm -f'. When the install-exec-hook target is executed, $(RM) is lost and bmake tries to execute @libbsd.so rather than forcibly removing it. I wouldn't strictly consider this a bug, as much as a portability concern, especially considering freedesktop doesn't mention gmake as a dependency for libbsd. This further reinforces my previous impression of libbsd being very linux-centric and hardly tested outside of Linux, in open contrast with the supposed goals of the project. I've committed a very simple a patch to wip/libbsd to address the problem (replacing $(RM) with `rm -f'in that single line) . Now libbsd works just as expected, at least with my packages. Another way to address to problem would be to redefine pkgsrc's RM in the package Makefile and pass it to libbsd as a MAKEFLAG. Or add gmake to USE_TOOLS. Which approach is considered best? Putting the other considerations made in this thread temporarily aside I now consider libbsd (+libmd) ready to import. [1] 'Switch md5 compatibility logic back to direct linking' \ https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888 [2] https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html -- ----------------------------+---------------------------- vms[-at]retrobsd.ddns.net | https://retrobsd.ddns.net
Attachment:
signature.asc
Description: PGP signature