Makefile generation does not work on some platforms

Asked by Yves Pelletier on 2009-05-09

Attempting to compile libECBUFR on Ubuntu 9.04 (Jaunty) from the downloadable 0.8.0 tarball, I had the following problems, which prevented me from generating makefiles, let alone compiling.

Some Makefile.am files use the $(wildcard *.ext) construct. There is apparently a forward-compatibility issue with that. Also, this is only compatible with GNU make. One example error message:

API/Headers/Makefile.am:7: wildcard *.h: non-POSIX variable name
API/Headers/Makefile.am:7: (probably a GNU make extension)

This, or similar warnings, are generated in the following places:
API/Headers/
API/Headers/private/
Test/BUFR/
Test/Dump/

Question information

Language:
English Edit question
Status:
Solved
For:
libECBUFR Edit question
Assignee:
No assignee Edit question
Solved by:
Yves Pelletier
Solved:
2009-05-20
Last query:
2009-05-20
Last reply:
2009-05-11

 I worked through minor issues at my end and now a Makefile is generated; however when "make" is launched it fails on the first libtool call with a long series of messages similar to this one:

../../libtool: line 642: X--tag=CC: command not found

which seem to indicated that a series of character strings are being mistaken for commands.

Update: the "non-POSIX variable name" messages don't seem to be show-stoppers. But they are an indication that GNU make must be used.

The "command not found" errors, quoted above, were due to a libtool script generation issue. This is about the "libtool" script that is generated in the current directory when you run ./configure. In the script, a variable ECHO=echo is created but later on, when "echo" is needed, it is referred to as $echo (which has not been defined). There may be other similar glitches, as even when that one is fixed, the make still halts on errors later on.

This has happened before in other contexts, for instance here: https://bugs.launchpad.net/ubuntu/+source/libtool/+bug/285841 ; in this thread the Ubuntu libtool expert says this behaviour comes from using different version numbers of ltmain.sh and libtool. To be continued.

This issue was re-activated as a bug and resolved. (As far as we can tell).

This issue was re-activated as a bug and resolved in release 0.8.1. (As far as we can tell).