Makefile generation does not work on some platforms

[Yves Pelletier]

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/

[Yves Pelletier (yves-pelletier)]

 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.

[vanh souvanlasy (vanh-souvanlasy)]

Currently, in version 0.8.0, libtool's scripts are statically included in the package. These scripts works fine on systems similar to the one it came from, but seems to be uncompatible with ubuntu 9.04.
Actually, these scripts don't need to be included in the package, they should be customed according to the system on which the library is to be installed. Using "libtoolize --force" will regenerate it. This command will be added to the reconf script.

[vanh souvanlasy (vanh-souvanlasy)]

libtool scripts should be customed not statically included in the distribution

[vanh souvanlasy (vanh-souvanlasy)]

Attempts to compile this on UBUNTU 8.04 LTS were made. A few minor problems were found with the file
aclocal.m4 generated by aclocal, will need some adjustment in "reconf" script.

[vanh souvanlasy (vanh-souvanlasy)]

Changes made in Rev. 8 should do it, now reconf script calls 'autoreconf' instead of calling autoconf, automake, etc ... directly.

[Yves Pelletier (yves-pelletier)]

Configuration and compilation now work on my Ubuntu 9.04 machine.

[vanh souvanlasy (vanh-souvanlasy)]

Changes done in revision 8 solved this problem

[Scott Sinclair (scott-sinclair-za)]

I'm still unable to generate the make files with release 0.8.1 on Ubuntu 9.04.

$ ./reconf
*** Running libtoolize
*** This warning may appear the first time only: 'You should add the contents of...'
libtoolize: putting auxiliary files in `.'.
libtoolize: linking file `./ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize: `/usr/share/aclocal/libtool.m4'
libtoolize: `/usr/share/aclocal/ltoptions.m4'
libtoolize: `/usr/share/aclocal/ltversion.m4'
libtoolize: `/usr/share/aclocal/ltsugar.m4'
libtoolize: `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
*** Running autoreconf
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
API/Headers/Makefile.am:7: wildcard *.h: non-POSIX variable name
API/Headers/Makefile.am:7: (probably a GNU make extension)
API/Headers/private/Makefile.am:1: wildcard *.h: non-POSIX variable name
API/Headers/private/Makefile.am:1: (probably a GNU make extension)
Test/BUFR/Makefile.am:1: wildcard *.bufr: non-POSIX variable name
Test/BUFR/Makefile.am:1: (probably a GNU make extension)
Test/BUFR/Makefile.am:1: wildcard *.out: non-POSIX variable name
Test/BUFR/Makefile.am:1: (probably a GNU make extension)
Test/Dump/Makefile.am:1: wildcard *.template: non-POSIX variable name
Test/Dump/Makefile.am:1: (probably a GNU make extension)
Test/Dump/Makefile.am:1: wildcard *.dump: non-POSIX variable name
Test/Dump/Makefile.am:1: (probably a GNU make extension)
Test/Dump/Makefile.am:1: wildcard *.bufr: non-POSIX variable name
Test/Dump/Makefile.am:1: (probably a GNU make extension)
[: 19: 0: unexpected operator
$

[cpb (chris-beauregard)]

Shell syntax error in reconf; it's actually cosmetic since by the time you see the error, configure is generated and ready to go. The attached patch fixes the problem. I'll commit it when I'm behind a less restrictive firewall.

[Chuck Paterson (charles-paterson)]

Thanks Chris.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
cpb
Sent: Thursday, 2 July 2009 8:28 AM
To: Paterson,Charles [Ontario]
Subject: [Bug 374191] Re: Makefile generation does not work on some
platforms

Shell syntax error in reconf; it's actually cosmetic since by the time
you see the error, configure is generated and ready to go. The attached
patch fixes the problem. I'll commit it when I'm behind a less
restrictive firewall.

** Attachment added: "reconf-launchpad-374191.patch"
   http://launchpadlibrarian.net/28626167/reconf-launchpad-374191.patch

--
Makefile generation does not work on some platforms
https://bugs.launchpad.net/bugs/374191
You received this bug notification because you are a member of
libecbufr-dev, which is the registrant for libECBUFR.

Status in Environment Canada BUFR Library: Fix Committed

Bug description:
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/

[Scott Sinclair (scott-sinclair-za)]

Makefiles correctly produced (without the bogus error) after applying the patch. Thanks!

[cpb (chris-beauregard)]

Things are broken on Karmic, now.

[Yves Pelletier (yves-pelletier)]

Chris, can you be more specific?

I compiled and installed the current 0.8.2 from the trunk repository on Karmic on my home system. I ran the whole sequence: reconf, configure, make, sudo make install. There were some complaints, most notably about not being able to produce the .rtf version of the docs, but otherwise there was no show-stopper. The scripts could use some cleaning up, but I could not reproduce any major issue.

[cpb (chris-beauregard)]

cpb@tiny:~/src/lp/libecbufr-trunk$ sh reconf
...
configure.in:70: required file `./config.guess' not found
configure.in:70: `automake --add-missing' can install `config.guess'
configure.in:70: required file `./config.sub' not found
configure.in:70: `automake --add-missing' can install `config.sub'
...
autoreconf: automake failed with exit status: 1
*** Done. You may now run configure
cpb@tiny:~/src/lp/libecbufr-trunk$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
...
checking whether make sets $(MAKE)... (cached) yes
configure: error: cannot run /bin/bash ./config.sub
cpb@tiny:~/src/lp/libecbufr-trunk$

----------------------

Now, this _is_ a jaunty-to-karmic upgraded system, so that might be a factor.

[Yves Pelletier (yves-pelletier)]

configure.in:70: `automake --add-missing' can install `config.guess'

Ah yes :-) That was a few weeks ago for me when I first tried libECBUFR on Karmic. I did as I was told and ran
"automake --add-missing". That seems to have fixed it for me.

[cpb (chris-beauregard)]

Yeah, that would work. However, the "sh reconf && ./configure && make && make check" process should usually Just Work.

Fix is to add --install to the autoreconf call in the reconf script. I'll commit that when I've confirmed it works.

[cpb (chris-beauregard)]

Fix in r61.

[vanh souvanlasy (vanh-souvanlasy)]

this was fixed in 0.8.2 before release date 12/02/2009