0

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'

)

nostromo
  • 61
  • 1
  • 1
  • 11
  • 1
    The installation instructions say that the first thing to run is `./bootstrap`. I did that, and after doing a number of other things, it ran `autoreconf`, which produced a working `./configure`. – Mark Plotnick Apr 28 '23 at 11:04
  • Thank you Mr @MarkPlotnick, sounds great. The thing is... That overwrites the native m4 installation that came with my system (that i want to keep unaltered and spotless for not making a mess) or what you did, just produces a very local executable inside and sandboxed just in the folder where all the installation action took place? – nostromo Apr 28 '23 at 12:23
  • 2
    Why don't you just download the source tar package, rather than trying to build from a Git workspace? Building from Git requires a lot of extra "developer-only" tools and steps, that are already run for you if you download the source package. But, to install "somewhere else" just tell `configure` where you want to install. For example `./configure --prefix=$HOME/localstuff` then when you run `make install` it will put everything into `$HOME/localstuff/bin` etc., and not replace your system versions. – MadScientist Apr 28 '23 at 14:11
  • 1
    @MadScientist OP is trying to get a version of m4 that is as close as possible to the one used as an example in Stallman's 20-year-old GDB guide. Someone suggested extracting branch-1.4 from the git repo. – Mark Plotnick Apr 29 '23 at 16:09
  • 1
    Again I ask, why? You can just go to https://ftp.gnu.org/gnu/m4/ and download all the previously released versions, back to 1994, including m4 1.4. – MadScientist Apr 29 '23 at 18:26
  • @MadScientist Cool. Thanks. So, OP, https://ftp.gnu.org/gnu/m4/m4-1.4.tar.gz is another option for you. It compiles (with warnings) on a modern Ubuntu system. – Mark Plotnick Apr 29 '23 at 18:48

1 Answers1

1

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.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • 2
    You can run `make install` with no problem, if you configure the software to install somewhere other than your default system hierarchy. Just pass the `--prefix` option to `configure`, or else run `make DESTDIR=`. This is all discussed in the INSTALL or README files in the m4 source directory. – MadScientist Apr 28 '23 at 22:52
  • @MadScientist First, thx to you all (Plotnick; of course, Russian) for your attention and efforts. I have been doing tutorials on `autotools`. Not with the deepness i desire for the moment. I am going to try all your suggestions. I will try to compile both on diff folders. Over debate `make`/`make install`, i feel conservative and afraid. Some manuals didn’t foster second. Perhaps i am wrong, i understood system libraries or collateral files installation related, could be overwritten? Perhaps you could give me more advice on it. My deepest thanks to all of you. – nostromo May 08 '23 at 13:14
  • 1
    If you don't run your `make` command as root (don't use `sudo` for example) then there is no way you can overwrite system files since you won't have permissions. If you're worried about what will happen you can run `make -n install`: the `-n` tells make to just print the recipes without running them. Then you can see where things will be installed. But using `configure --prefix` is a time-honored way of installing "somewhere else" without disrupting your system. Everyone uses it. – MadScientist May 08 '23 at 13:33
  • @MadScientist /Russian Starting with 1994 version: until now looks like everything went perfect: downloaded tar.gz, `tar -xvf ...`, then `./configure --prefix=/home/debugging/DWGDB_STALLMAN/M4_1994` (was it possible just `--prefix=.` or `--prefix=..`?), checked with `make check` and `make -n`. Did `make`: now i found an `m4` executable in `src` folder. That exec would be fully working or i need to do inevitably `make install` (obviously there is already no /bin & no other things in the folder i indicated in --prefix) ? – nostromo May 10 '23 at 09:06
  • @MadScientist (et al.) I found this: https://stackoverflow.com/questions/16637860/why-make-before-make-install By the way, in case there can be thought there was effort and could be also a matter of interest that may help others, i would really appreciate receiving an upvote for my question. Thank you very much. ;D – nostromo May 10 '23 at 09:58
  • 1
    Whether or not you can invoke the utility directly without installing it, depends entirely on the utility. Some (`m4` is likely in this category) are stand-alone programs with no extra files needed and so you can just run them where they were built. Other programs require extra files to be installed alongside the program and may not work properly without them, and these you need to run `make install` first. – MadScientist May 10 '23 at 12:41
  • Thank you very much @MadScientist . Until i get stuck in this process of this `m4` thing i would like to take the opportunity to ask you two questions: first, looking your SO questions log, looks you are really into the `autotools` thing. I would like to improve my knowledge on it. From what you know today, what would be a nice source/s (texts, videos, etc) for it? – nostromo May 12 '23 at 06:18
  • Second, i have been reading pdfs & watching videos on `git` (most due to EmployedRussian post) & is a tool encountered very frequently so i don't want to avoid it. I want to feel comfortable on it for basic things. I know is for version-control/many-people-working-on-same-project tool. So, same as first question. But also, why do you recommend keeping far from it? I mean, relating in a basic way with repositories (i.e. no needing to do things like... `git commit`, etc) , would be equivalent as getting packages, sources, etc... As with any other tools? Where is the point of not recommending it? – nostromo May 12 '23 at 06:22
  • 1
    I recommend reading the manuals provided by the GNU project: https://www.gnu.org/doc/doc.en.html As for Git, I have no idea why you think I recommend staying away from it. I use it myself all day every day and I enjoy using it. It is maybe not the most user-friendly tool but it's extremely powerful and useful and especially if you have the right front-end (I use Magit in Emacs) it is great. – MadScientist May 12 '23 at 13:12
  • Again, I would start with the official GNU site which has a good introduction: https://www.gnu.org/software/emacs/ Modern vi is also very customizable and has the ability to run extensions but Emacs is the O.G. extendable editor. – MadScientist May 12 '23 at 14:45