Build failure in openocd

[eagerm]

I'm running into a build error: $ cd freedom-e-sdk $ make tools rm -rf work/build/openocd/ mkdir -p work/build/openocd/ cd freedom-e-sdk/openocd; autoreconf -i Makefile.am:46: warning: wildcard $(srcdir: non-POSIX variable name Makefile.am:46: (probably a GNU make extension) Makefile.am:22: error: Libtool library used but 'LIBTOOL' is undefined Makefile.am:22: The usual way to define 'LIBTOOL' is to add 'LT_INIT' Makefile.am:22: to 'configure.ac' and run 'aclocal' and 'autoconf' again. Makefile.am:22: If 'LT_INIT' is in 'configure.ac', make sure Makefile.am:22: its definition is in aclocal's search path. autoreconf: automake failed with exit status: 1 make: *** [work/build/openocd/configure.stamp] Error 1

I have the following installed: $ libtool --version libtool (GNU libtool) 2.4.2 $ libtoolize --version libtoolize (GNU libtool) 2.4.2 $ autoreconf --version autoreconf (GNU Autoconf) 2.69 $ automake --version automake (GNU automake) 1.14 $ pkg-config --version
0.27.1

[jim-wilson]

openocd/Makefile.in says it was generated by automake 1.15. So it looks like it won't work with automake 1.14. Otherwise the version numbers look OK. automake-1.15 was released in 2014, and is included in Ubuntu 16.04 which is what we tend to use around here, so it doesn't seem unreasonable to be using it.

It looks a little annoying that the freedom-e-sdk is explicitly running autoreconf. I don't know why it is doing that. That will force users building this to have the right autoconf and automake versions which is inconvenient.

[eagerm]

I installed automake-1.15, but I get the same errors.

It looks a little annoying that the freedom-e-sdk is explicitly running autoreconf. I don't know why it is doing that. That will force users building this to have the right autoconf and automake versions which is inconvenient.

It looks like this is so that they don't have to check a generated Makefile into the repo. Not the choice I would make.

[jim-wilson]

What distro and version are you building on? I can try to reproduce your build environment on a spare machine.

Your guess about the Makefile looks reasonable. Perhaps they are trying to avoid differences from the upstream repository, and don't want autoconf/automake artifacts getting in the way.

[eagerm]

I'm running CentOS 7.4. I can set up an Ubuntu build system but I prefer CentOS. Thanks for your help.

[jim-wilson]

I reproduced the problem on a CentOS 7.4.1 machine.

The LT_INIT error is due to the libtoolize version. If I install libtool-2.4.6 it goes away, but then I get other errors due to automake/autoconf. To make that work, you need an automake-1.15 build and install as mentioned before, and I also had to do an autoconf-2.69 build and install even though autoconf-2.69 is the native CentOS autoconf version. I think there might be some interaction between automake and autoconf that requires them installed into the same dir, or maybe autoconf does version checks on automake, and hence has to be rebuilt afterward. Anyways, I just ran configure with no options to install into /usr/local/bin and had to do that for both, first automake, then autoconf. With that done, the "make openocd" command is now passing the autoreconf -i command, and failing with an error in the configure script because PKG_PROG_PKG_CONFIG is undefined. This macro apparently comes from the separate pkg-config package, and is present in /usr/share/aclocal/pkg.m4 file, but there is no such file in /usr/local/share/aclocal. So I had to copy it over. There are also other files in there from other packages, but openocd doesn't need them. Now "make openocd" is working, though that was an awful lot of trouble to go through. And it might leave your system in a slightly broken state, if you need the original automake/autoconf/libtool versions to build CentOS packages. I would suggest not installing automake/autoconf/libtool in /usr/local, and instead putting them in some directory that you only add to your path when trying to build openocd.

[eagerm]

Thanks. That sounds like it was a bit of work to sort out. I'll try this as soon as I can.

[stefanct]

I can confirm that this is a nightmare and by far the easiest approach is to simply compile the whole autocrap environment from source. Anyone who wants to follow our route through those hoops might find these useful:

# build libtool
git clone git://git.savannah.gnu.org/libtool.git
cd libtool
./bootstrap
./configure --prefix ~/.local/
make install

# build automake
git clone git://git.savannah.gnu.org/automake.git
cd automake
git checkout v1.16.3
./bootstrap
./configure --prefix ~/.local/
make install

# build autoconf
git clone https://git.savannah.gnu.org/git/autoconf.git
cd autoconf
git checkout v2.72b
autoreconf -vi
make install

# pkg-config
git clone https://gitlab.freedesktop.org/pkg-config/pkg-config.git
cd pkg-config
git checkout pkg-config-0.29.2
NOCONFIGURE=1 ./autogen.sh
./configure --prefix ~/.local/
make install

[eagerm]

Building project-specific versions of Automake, Autoconf, and Libtool is annoying. I'm not sure about pkg-config, since that gets called during a build.

My suggestion would be to generate the Makefile and configure using the correct Automake/Autoconf/Libtool versions and check them into the repo. That way only one person has the pain, not everyone.