This “maze”, started in an innocent way: “just to debug with gdb an executable proposed on a book”. The program chosen by the author of this “learn how to debug book”, was this m4 macro processor. The problem is that m4 is already present in my linux (as in many others as many people know) in its latest version and is a critical program used for many tasks. So not a good target to tweak directly with. I posted a question this past 11th feb 2023 (SO link below) and I received a lot of useful help. Before going with the instructions of the answer I decided to get a bit more literate in configure, make, make install and also git (quite interesting all of those. Targets, labels, alias, hierarchy, etc). To get a more deep grasp of what I was going to do, not just typing commands blindly.

I opted for the second option in this post answer (chosen m4’s year 2000 repo version, instead the 1988 version who would have added an extra level of difficulty, i.e. having to tweak or even build a gcc version that would have accepted those 1988’s sources).

After going through the problems experienced (see below), my present question is:

Wouldn't be possible to just do a gcc -o m4 foo.c bar.c .... etc... and generate an executable purely local to the folder to experiment directly with GDB (that was from the beginning the main objective of all this). Avoiding any conflict with the legitimate/native m4 and also avoiding overriding (i.e. writing on /bin/m4) the exiting and up to date m4 installation. Is this simply a matter of “flags” on the building scripts? How can this be done? 

End goal is to be able to do this simple:

gdb ./m4

(and putting bugs on purpose on m4's *.c sources code and following all the book has to teach. The first bug part was already solved by the commentator in the ancient post. But first I have to get this to compile and build the (local) executable. Otherwise I cannot do anything).

(This journey, started here: Stuck in Stallman's GDB book trying debug m4 (macro processor) 'bug' example: m4 executable i have is a direct bin in /bin (nothing ".../gnu/ ./m4")

This all was retrieved with git:

$ git clone git://git.sv.gnu.org/m4
$ git checkout branch-1.4

This is what I did: This is how the folder looks like:

$ ls
acinclude.m4    build-aux       configure     gnulib       NEWS    TODO
AUTHORS         c-boxes.el      configure.ac  HACKING      po
autom4te.cache  cfg.mk          COPYING       INSTALL      README
BACKLOG         ChangeLog-2014  doc           lib          src
bootstrap       checks          examples      m4           tests
bootstrap.conf  config.log      gl            Makefile.am  THANKS

This when I type autoreconf:

$ autoreconf
configure.ac:230: warning: macro 'AM_GNU_GETTEXT' not found in library
configure.ac:231: warning: macro 'AM_GNU_GETTEXT_VERSION' not found in library
sh: 1: build-aux/git-version-gen: not found
configure.ac:25: error: AC_INIT should be called with package and version arguments
/usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:25: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal: error: /usr/bin/autom4te failed with exit status: 1
autoreconf: error: aclocal failed with exit status: 1

This when I type autoconf configure.ac:

$ autoconf configure.ac
-- snippet (just the errors) --
configure.ac:25: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:27: error: possibly undefined macro: AM_SILENT_RULES
configure.ac:36: error: possibly undefined macro: M4_EARLY
configure.ac:155: error: possibly undefined macro: M4_INIT
configure.ac:223: error: possibly undefined macro: M4_WITH_DMALLOC
configure.ac:230: error: possibly undefined macro: AM_GNU_GETTEXT
configure.ac:231: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION
           

This when I type ./configure:

$ ./configure 

./configure: line 2273: syntax error near unexpected token `1.11.6'
./configure: line 2273: `AM_INIT_AUTOMAKE(1.11.6 dist-bzip2 dist-xz color-tests parallel-tests'

)

1

There are 1 best solutions below

10
Employed Russian On BEST ANSWER

Mark Plotnik> run ./bootstrap, then autoreconf.

Thank you Mr @MarkPlotnick, sounds great. The thing is... That overwrites the native m4 installation

No, it does not.

It creates a Makefile, which you can use to build and debug a local build of m4.

The Makefile would overwrite native m4 installation only if you do make install (don't do that).

P.S. To answer the original "possible to just do a gcc -o m4 foo.c bar.c ....", the answer is yes, but it requires a config.h file.

You could write config.h by hand, but that is somewhat hard to do. Normally this file is produced by running ./configure, and you'll be much better off getting a working ./configure by using ./bootstrap and autoreconf.