Bug 3796 - aclocal fails with 'cannot open ...'
Summary: aclocal fails with 'cannot open ...'
Status: CLOSED NOTABUG
Alias: None
Product: Sisyphus
Classification: Development
Component: automake_1.8 (show other bugs)
Version: unstable
Hardware: all Linux
: P1 blocker
Assignee: Dmitry V. Levin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-06 00:27 MSK by Mikhail Zabaluev
Modified: 2005-07-13 15:45 MSD (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Zabaluev 2004-03-06 00:27:01 MSK
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 Dmitry V. Levin 2004-03-06 02:47:29 MSK
Well, all previous automake versions ignored this m4_include expression completely, 
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.