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

Previous Next

To reply to this bug, email your comments to 31728 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: bug-automake <at> gnu.org
Subject: Automake and AM_WITH_DMALLOC; endorsing proprietary software?
Date: Tue, 5 Jun 2018 15:09:29 -0400

Hi,

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.

The trouble is that dmalloc appears to be non-free: the license does
not seem to permit distribution for a fee (see below).  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.

The license text found in the latest dmalloc 5.5.2 release is this:

  Copyright 2000 by Gray Watson

  Permission to use, copy, modify, and distribute this software for
  any purpose and without fee is hereby granted, provided that the
  above copyright notice and this permission notice appear in all
  copies, and that the name of Gray Watson not be used in advertising
  or publicity pertaining to distribution of the document or software
  without specific, written prior permission.

  Gray Watson makes no representations about the suitability of the
  software described herein for any purpose.  It is provided "as is"
  without express or implied warranty.

The permission grant is almost identical to the ISC license except that
"and/or" is changed to "and" and, more importantly, the words "with or
without fee" are changed to "and without fee".

[1] https://www.gnu.org/software/automake/manual/automake.html#index-AM_005fWITH_005fDMALLOC

Thoughts?

Cheers,
  Nick

Message #8 received at 31728 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: 31728 <at> debbugs.gnu.org
Subject: Re: 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

Message #11 received at 31728 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: nbowler <at> draconx.ca, 31728 <at> debbugs.gnu.org
Subject: Re: bug#31728: Automake and AM_WITH_DMALLOC;
 endorsing proprietary software?
Date: Sat, 11 Dec 2021 15:42:48 -0700

Mike,

    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.

I also agree, but I still wouldn't want to delete the macro and thus
gratuitously break people's working automake setups.  People might well
have AM_WITH_DMALLOC left over from when they were debugging 20 years
ago.  There is no reason to make them spend time thinking about it now,
IMHO -- even if all they have to do is remove it, that's too much to ask
for no actual gain.

Instead, let's update the doc to recognize the situation.
Can you draft something, mentioning the other tools, along the lines of
what you wrote in this email?

If anyone ever comes along with a need for dmalloc or to update the
macro (unlikely), we could go further then.

If dmalloc were (still) nonfree, it would be a different story.

Thanks,
Karl

Message #14 received at 31728 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: nbowler <at> draconx.ca, 31728 <at> debbugs.gnu.org
Subject: Re: bug#31728: Automake and AM_WITH_DMALLOC; endorsing proprietary
 software?
Date: Sat, 11 Dec 2021 22:37:16 -0500

[Message part 1 (text/plain, inline)]

On 11 Dec 2021 15:42, Karl Berry wrote:
>     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.
> 
> I also agree, but I still wouldn't want to delete the macro and thus
> gratuitously break people's working automake setups.  People might well
> have AM_WITH_DMALLOC left over from when they were debugging 20 years
> ago.  There is no reason to make them spend time thinking about it now,
> IMHO -- even if all they have to do is remove it, that's too much to ask
> for no actual gain.
> 
> Instead, let's update the doc to recognize the situation.
> Can you draft something, mentioning the other tools, along the lines of
> what you wrote in this email?
> 
> If anyone ever comes along with a need for dmalloc or to update the
> macro (unlikely), we could go further then.

i think we can still mark it obsolete even if we don't plan on deleting it
for a while.  that should at least prevent new users from showing up, and
slowly encourage people to remove existing usage.
-mike

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 31728 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: 31728 <at> debbugs.gnu.org
Subject: [PATCH] dmalloc: mark macro as obsolete
Date: Tue, 18 Jan 2022 01:23:34 -0500

This macro doesn't really fit in with Automake's mission.  It's a simple
configure option to add a specific library when linking.  Maybe back in
1996 the dmalloc project was more canonical, but nowadays developers have
a wealth of options when it comes to memory debugging, 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).  We can't really add value by trying to track all
of them, and dmalloc itself seems to have fallen significantly in use.

Lets mark it obsolete and start issuing warnings whenever anyone tries
to use it.  Considering we've had it in automake for 2 decades, we can
probably keep it around for a while still in warning mode to give users
ample time to migrate.

This was suggested in https://debbugs.gnu.org/31728.

* doc/automake.texi: Move AM_WITH_DMALLOC to Obsolete Macros chapter.
* m4/dmalloc.m4: Call m4_warn(obsolete) when used.
---
 doc/automake.texi | 21 ++++++++++++---------
 m4/dmalloc.m4     |  5 ++++-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index 9916a41d4b79..ae7a49cba247 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -4170,15 +4170,6 @@ the @command{missing} script is appropriate.
 Control the machinery for less verbose build output
 (@pxref{Automake Silent Rules}).
 
-@item AM_WITH_DMALLOC
-@acindex AM_WITH_DMALLOC
-@cindex @command{dmalloc}, support for
-@vindex WITH_DMALLOC
-@opindex --with-dmalloc
-Add support for the @uref{https://dmalloc.com/, Dmalloc package}.  If
-the user runs @command{configure} with @option{--with-dmalloc}, then
-define @code{WITH_DMALLOC} and add @option{-ldmalloc} to @code{LIBS}.
-
 @end table
 
 
@@ -4218,6 +4209,18 @@ you are advised to switch ASAP to the more modern Autoconf-provided
 interface instead; both the macro and the variable might be removed
 in a future major Automake release.
 
+@item AM_WITH_DMALLOC
+@acindex AM_WITH_DMALLOC
+@cindex @command{dmalloc}, support for
+@vindex WITH_DMALLOC
+@opindex --with-dmalloc
+
+Add support for the @uref{https://dmalloc.com/, Dmalloc package}.  If
+the user runs @command{configure} with @option{--with-dmalloc}, then
+define @code{WITH_DMALLOC} and add @option{-ldmalloc} to @code{LIBS}.
+
+This macro is @emph{deprecated} and will be removed in a future release.
+
 @end table
 
 
diff --git a/m4/dmalloc.m4 b/m4/dmalloc.m4
index 66d943e4de4c..eecb7e4186f8 100644
--- a/m4/dmalloc.m4
+++ b/m4/dmalloc.m4
@@ -10,7 +10,10 @@
 # with or without modifications, as long as this notice is preserved.
 
 AC_DEFUN([AM_WITH_DMALLOC],
-[AC_MSG_CHECKING([if malloc debugging is wanted])
+[m4_warn([obsolete],
+['$0': this macro is obsolete.
+You should add your own configure and link tests instead.])dnl
+AC_MSG_CHECKING([if malloc debugging is wanted])
 AC_ARG_WITH([dmalloc],
 [AS_HELP_STRING([--with-dmalloc],
                 [use dmalloc, as in http://www.dmalloc.com])],
-- 
2.33.0

Message #20 received at 31728 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 31728 <at> debbugs.gnu.org
Subject: Re: bug#31728: [PATCH] dmalloc: mark macro as obsolete
Date: Tue, 18 Jan 2022 16:15:06 -0700

To me, the question is, does the current AM_WITH_DMALLOC actually work?
Or not?  If it does, I see no reason to have it issue a warning, and
thus annoy anyone who has it in their configure.ac, where it is
presumably residing harmlessly.

I agree it does not "fit with Automake's mission", and wouldn't want to
add any similar macros, but to me that's not enough reason to
"deprecate" something that's been part of Automake for so long.

I feel strongly that the macro should never be deleted, useless though
it may be(come). -k

Message #23 received at 31728 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 31728 <at> debbugs.gnu.org
Subject: Re: bug#31728: [PATCH] dmalloc: mark macro as obsolete
Date: Tue, 18 Jan 2022 22:07:40 -0500

[Message part 1 (text/plain, inline)]

On 18 Jan 2022 16:15, Karl Berry wrote:
> To me, the question is, does the current AM_WITH_DMALLOC actually work?
> Or not?  If it does, I see no reason to have it issue a warning, and
> thus annoy anyone who has it in their configure.ac, where it is
> presumably residing harmlessly.

how are you defining "work" ?  all it does is add -ldmalloc to $LIBS.
it doesn't verify the library actually exists, or that it's even the
right library for the language (-ldmalloc is for C while -ldmallocxx
is for C++, and there's another for threaded projects).

it also adds -g to LDFLAGS ... for some reason.  i assume it wanted
to use -g in CFLAGS instead so it has access to debugging information.
afaict, -g doesn't actually do anything with linkers ... GNU ld ignores
it for historical compatibility with other tools, and it has for over
20 years (git history stops at 1999).

so it works in that it's syntactically valid shell code, and uses the
right autoconf macros, but it doesn't really work in the sense that
users care about and actually want to rely on.

> I agree it does not "fit with Automake's mission", and wouldn't want to
> add any similar macros, but to me that's not enough reason to
> "deprecate" something that's been part of Automake for so long.

imo automake should be providing a curated experience, not get bogged
down under its own historical baggage, or provide macros that (frankly)
are not that useful or maintained.

in the case of this macro, we can see it has at least 4 issues:
* outdated homepage
* bad language/runtime support
* lacks proper detection (e.g. compile/link tests)
* uses useless/obsolete flags (LDFLAGS=-g)

rather than continue to provide a disservice to our users and put up a
facade that we're actually keeping this thing healthy, just cut it off.
i strongly doubt anyone will care.

it's also a drain on us.  when we need to update macros or cleanup style
or similar house keeping tasks, this is a time suck.  we spend energy on
code no one uses.  i won't argue it's a *lot* of time, but it's def not
zero.  i'd rather we spend that time doing what we should be doing :).

> I feel strongly that the macro should never be deleted, useless though
> it may be(come). -k

let's deprecate it and we can circle back in a decade to see if you still
think we should keep it.
-mike

[signature.asc (application/pgp-signature, inline)]

Message #26 received at 31728 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 31728 <at> debbugs.gnu.org
Subject: Re: bug#31728: [PATCH] dmalloc: mark macro as obsolete
Date: Sat, 22 Jan 2022 14:44:11 -0700

Sorry, I still disagree with "deprecating" AM_WITH_DMALLOC (or anything
else). My wish would be to add some strong wording in the manual about
how it doesn't do anything especially useful, new code shouldn't use it,
etc., and let it go at that.

I don't argue that AM_WITH_DMALLOC is useful.  But since it has been
there forever, I argue that deprecating it is harmful, in that it causes
gratuitous work for maintainers whose configure.ac's happen to have it.

Having been forced to waste more of my time than I care to think about
because some upstream maintainer decided to "clean up" their interface
or code, and deprecate/remove perfectly fine, or at least not harmful,
macros/functions/options/whatever, I (strongly) don't want to inflict
that on anyone else.

As far as I can see, the only way AM_WITH_DMALLOC will cause any problem
to anyone is if we deprecate/remove it. No one has ever complained about
it outside of this bug, so far as I know. So how about if we save
everyone time and trouble and do nothing to it? -k

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Zack Weinberg" <zack <at> owlfolio.org>
To: bug-automake <at> gnu.org
Subject: Re: bug#31728: [PATCH] dmalloc: mark macro as obsolete
Date: Mon, 24 Jan 2022 09:02:19 -0500

On Sat, Jan 22, 2022, at 4:44 PM, Karl Berry wrote:
> Sorry, I still disagree with "deprecating" AM_WITH_DMALLOC (or anything
> else). My wish would be to add some strong wording in the manual about
> how it doesn't do anything especially useful, new code shouldn't use it,
> etc., and let it go at that.

I understand where you are coming from but I want to make a counterargument.
Autotools in general have a problem where there are lots of macros that
solve problems that are no longer important, but people keep including them
in configure.ac anyway, because they don't realize that they are no longer
important.  Often the code doesn't actually work in the situation the macro
is testing for, because they haven't been diligent enough with the #ifdefs
or whatever, and nobody notices.

Putting strong wording in the manual is not enough to get people to stop
using these macros in new code, because people aren't reading the manual,
they are copying configure.ac fragments from other programs (which may or
may not have been written back in the day when the portability problems
addressed by the macros _were_ still important).

> I don't argue that AM_WITH_DMALLOC is useful.  But since it has been
> there forever, I argue that deprecating it is harmful, in that it causes
> gratuitous work for maintainers whose configure.ac's happen to have it.

Deprecation warnings are a blunt instrument, and I appreciate that they
make extra work for maintainers, but I will argue that that extra work
is _worthwhile_ work because it means their configure.ac's become
_better examples_ for the sorts of people who want to copy and tinker
existing code rather than reading documentation.

zw

Previous Next

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