GNU bug report logs - #31728
Automake and AM_WITH_DMALLOC; endorsing proprietary software?

Previous Next

Full log

View this message in rfc822 format

From: Mike Frysinger <vapier <at> gentoo.org>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: 31728 <at> debbugs.gnu.org
Subject: bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary software?
Date: Fri, 10 Dec 2021 02:29:29 -0500

confirm 31728
severity 31728 wishlist

On 05 Jun 2018 15:09, Nick Bowler wrote:
> The trouble is that dmalloc appears to be non-free: the license does
> not seem to permit distribution for a fee (see below).

first this part.  ianal, so i won't try to interpret the nuance here,
but it seems a bit mooted with the latest dmalloc which explicitly
switches to the ISC license and the OSI recognizes that as open source.

that said ...

> I have some doubts about the automake-provided macro AM_WITH_DMALLOC.
> This appears to be a development tool which could be useful to help
> programmers debug their packages.  It has a very brief description
> in the Automake manual in section 6.4.1 "Public Macros"[1], including
> a link to the dmalloc website.
> 
> This macro in
> Automake doesn't seem to exist for any real portability purpose, but
> rather it only adds options that help extend program functionality
> with this library.
> 
> Perhaps I am mistaken, but I wonder if this macro has a place in a
> GNU package like Automake.  The manual entry may encourage developers
> to use this macro/library.  For an example of this, GNU make 4.2.1
> did make use of the AM_WITH_DMALLOC macro, so in turn that package's
> configure --help output suggests this tool for debugging.

i tend to agree with this sentiment that the macro doesn't really fit
with automake's mission.  and more importantly, i think the ecosystem
has grown significantly since the macro was first added back in 1996.
we are not hurting for memory checking tools nowadays, both from ones
based in compile-time instrumentation (e.g. the various GNU sanitizers),
to ones that work at runtime only (e.g. valgrind and GNU C library's
various M_* env vars).  i don't think we can add value by adding macros
for each tech stack, and the number of users of dmalloc i think has
fallen off a cliff.

so imo we should deprecate this macro (i guess in the 1.17 release) and
then drop it entirely (i guess in the 1.18+ release).
-mike

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.