Bug 3796 - aclocal fails with 'cannot open ...'
: aclocal fails with 'cannot open ...'
: Sisyphus
(All bugs in Sisyphus/automake_1.8)
: unstable
: all Linux
: P1 blocker
Assigned To:
  Show dependency tree
Reported: 2004-03-06 00:27 by
Modified: 2005-07-13 15:45 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2004-03-06 00:27:01
If aclocal from automake_1.8 is invoked in a package directory, it fails with an
error reporting that it cannot open a certain .m4 file required by the package's
autotools macro files. Weirdest of all is that the file apparently has been
found first by a macro definition contained within it.
Any aclocal from earlier major versions of automake does not report such an error.

Steps to Reproduce:
1. Make sure automake_1.8 is installed.
2. Unpack opencdk-0.5.3 source archive from the opencdk source package.
3. Set environment variable AUTOMAKE_VERSION=1.8
4. Change to the source directory opencdk-0.5.3 and run aclocal
Actual Results:  
aclocal-1.8: cannot open libgcrypt.m4: No such file or directory
------- Comment #1 From 2004-03-06 02:47:29 -------
Well, all previous automake versions ignored this m4_include expression
you can see this by just renaming libgcrypt.m4 to foobar.m4. 

Since m4_include doesn't use dirlist (according to documentation, it just opens
the file given as 
argument), I see no error in aclocal behaviour. 

In opencdk package, you should remove both aclocal.m4 and acinclude.m4 files. 
Automake should find all necessary macros using its dependency tracker logic.