bug#7379: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
[ Thanks Glenn for rerouting the bug report! ] Hi Behdad, From: Behdad Esfahbod Subject: On the fix for CVE-2009-4029 Automake security fix for 'make dist*' Date: Thu, 11 Nov 2010 16:17:22 -0500 I recently read about the fix for the chmod 777 issue. Just wanted to note that it may be preferred if you continue with chmod 777 and instead fix the problem by moving the dist dir inside another direction that is 700. The reason a 777 mod in the tarball may be preferred (or 775 for that matter, but not 755) is for systems that users of a group are using sticky-bit on the group to share writable files with eachother. By letting the umask decide what bits should not be set you you enable such settings, whereas using 755, the user expanding the tarball has to reset it to 775 or the rest of the group cannot write to it. Thanks for the bug report. At the time we fixed this, we considered going this other option. It was a fairly close call. The downside of the solution you suggest was that it would complicate 'make dist' a little, and maybe break a few packages that rely on the exact subdir structure of $(distdir) being one directory below the toplevel build directory. Such reliance is probably bad style anyway, but we didn't know of many uses that would benefit from more relaxed permission inside the tarball. How useful is that for you, how come you don't use a version control repository rather than an extracted tarball for collaborative work (honest question)? You are the first person to report this in the 12 months since we released fixed versions of Automake. I don't have other data to go on but it thus doesn't seem to be a very wide spread issue to me, and there's the obvious workaround of a chmod -R after extraction, no? I'm open to arguments here, but so far I'm slightly leaning toward keeping the current behavior. Thanks, Ralf
[PATCH] {master} Deprecate obsoleted macro AM_WITH_REGEX.
OK for master?
* m4/regex.m4: Document the `AM_WITH_REGEX' macro as obsoleted,
and tell that it should be removed two years from now.
(AM_WITH_REGEX): Raise an m4-time warning of the obsolete
category when this macro is used.
* doc/automake.texi (Public Macros): Move description of
`AM_WITH_REGEX' from here ...
(Private Macros): ... to here, and declare it as obsoleted and
to be removed in a future version.
* tests/regex-obsolete.test: New test.
* tests/Makefile.am (TESTS): Update.
---
ChangeLog | 14 ++
doc/automake.texi | 27 ++-
m4/regex.m4 | 13 -
tests/Makefile.am |1 +
tests/Makefile.in |1 +
5 files changed, 38 insertions(+), 18 deletions(-)
From e667e058bbc45231bd64e761156449813ff5d4bc Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sat, 13 Nov 2010 12:21:28 +0100
Subject: [PATCH] Deprecate obsoleted macro AM_WITH_REGEX.
* m4/regex.m4: Document the `AM_WITH_REGEX' macro as obsoleted,
and tell that it should be removed two years from now.
(AM_WITH_REGEX): Raise an m4-time warning of the obsolete
category when this macro is used.
* doc/automake.texi (Public Macros): Move description of
`AM_WITH_REGEX' from here ...
(Private Macros): ... to here, and declare it as obsoleted and
to be removed in a future version.
* tests/regex-obsolete.test: New test.
* tests/Makefile.am (TESTS): Update.
---
ChangeLog | 14 ++
doc/automake.texi | 27 ++-
m4/regex.m4 | 13 -
tests/Makefile.am |1 +
tests/Makefile.in |1 +
5 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 24b20ae..93a6b1d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2010-11-13 Stefano Lattarini stefano.lattar...@gmail.com
+
+ Deprecate obsoleted macro AM_WITH_REGEX.
+ * m4/regex.m4: Document the `AM_WITH_REGEX' macro as obsoleted,
+ and tell that it should be removed two years from now.
+ (AM_WITH_REGEX): Raise an m4-time warning of the obsolete
+ category when this macro is used.
+ * doc/automake.texi (Public Macros): Move description of
+ `AM_WITH_REGEX' from here ...
+ (Private Macros): ... to here, and declare it as obsoleted and
+ to be removed in a future version.
+ * tests/regex-obsolete.test: New test.
+ * tests/Makefile.am (TESTS): Update.
+
2010-11-08 Stefano Lattarini stefano.lattar...@gmail.com
Improve and extend tests on man pages support.
diff --git a/doc/automake.texi b/doc/automake.texi
index 5ae565c..bee7d6c 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3921,19 +3921,6 @@ Add support for the @uref{http://dmalloc.com/, Dmalloc package}. If
the user runs @command{configure} with @option{--with-dmalloc}, then
define @code{WITH_DMALLOC} and add @option{-ldmalloc} to @code{LIBS}.
-...@item AM_WITH_REGEX
-...@acindex AM_WITH_REGEX
-...@vindex WITH_REGEX
-...@opindex --with-regex
-...@cindex regex package
-...@cindex rx package
-Adds @option{--with-regex} to the @command{configure} command line. If
-specified (the default), then the @samp{regex} regular expression
-library is used, @file{regex.o} is put into @code{LIBOBJS}, and
-...@code{with_regex} is defined. If @option{--without-regex} is given, then
-the @code{rx} regular expression library is used, and @file{rx.o} is put
-into @code{LIBOBJS}.
-
@end table
@@ -4009,6 +3996,20 @@ system. If so, set the shell variable @code{am_cv_sys_posix_termios} to
@samp{yes}. If not, set the variable to @samp{no}. This macro is obsolete,
you should use Autoconf's @code{AC_SYS_POSIX_TERMIOS} instead.
+...@item AM_WITH_REGEX
+...@acindex AM_WITH_REGEX
+...@vindex WITH_REGEX
+...@opindex --with-regex
+...@cindex regex package
+...@cindex rx package
+Adds @option{--with-regex} to the @command{configure} command line. If
+specified (the default), then the @samp{regex} regular expression
+library is used, @file{regex.o} is put into @code{LIBOBJS}, and
+...@code{with_regex} is defined. If @option{--without-regex} is given, then
+the @code{rx} regular expression library is used, and @file{rx.o} is put
+into @code{LIBOBJS}. This macro is obsolete now (since rx doesn't seem
+to be maintained), and will be removed in a future version of Automake.
+
@end table
diff --git a/m4/regex.m4 b/m4/regex.m4
index c05bb38..d8c4d6d 100644
--- a/m4/regex.m4
+++ b/m4/regex.m4
@@ -1,18 +1,21 @@
## - ## -*- Autoconf -*-
## Check if --with-regex was given. ##
## - ##
-# Copyright (C) 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
-# Free Software Foundation, Inc.
+# Copyright (C) 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
+# 2010 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is
Re: [PATCH] {master} Deprecate obsoleted macro AM_WITH_REGEX.
* Stefano Lattarini wrote on Sat, Nov 13, 2010 at 12:32:49PM CET:
* m4/regex.m4: Document the `AM_WITH_REGEX' macro as obsoleted,
I think technically obsolete is right here, without trailing d.
and tell that it should be removed two years from now.
s/tell/state/
(AM_WITH_REGEX): Raise an m4-time warning of the obsolete
category when this macro is used.
* doc/automake.texi (Public Macros): Move description of
`AM_WITH_REGEX' from here ...
(Private Macros): ... to here, and declare it as obsoleted and
Did you mean (Obsolete Macros) here?
to be removed in a future version.
* tests/regex-obsolete.test: New test.
That file is missing from the patch. Please resend and I'll finish the
review.
* tests/Makefile.am (TESTS): Update.
+...@item AM_WITH_REGEX
+...@acindex AM_WITH_REGEX
+...@vindex WITH_REGEX
+...@opindex --with-regex
+...@cindex regex package
+...@cindex rx package
+Adds @option{--with-regex} to the @command{configure} command line. If
+specified (the default), then the @samp{regex} regular expression
+library is used, @file{regex.o} is put into @code{LIBOBJS}, and
+...@code{with_regex} is defined. If @option{--without-regex} is given, then
+the @code{rx} regular expression library is used, and @file{rx.o} is put
+into @code{LIBOBJS}. This macro is obsolete now (since rx doesn't seem
+to be maintained), and will be removed in a future version of Automake.
Is rx a package? Where did you find traces to it?
How about adding Consider using gnulib if you need regex
functionality.?
@end table
Thanks,
Ralf
Re: [PATCH 1/3] aclocal: handle ACLOCAL_PATH environment variable
* Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:38PM CET:
This updated patch passes the tests suggested by Stefano. Considering
that Automake will rarely if ever be invoked from outside, MSYS, I stuck
with the colon as the sole separator for ACLOCAL_PATH.
The test suites leaves the user's ACLOCAL_PATH in place, for consistency
with the treatment of ${prefix}/share/aclocal/dirlist in tests/defs.in,
but overrides it in the two dedicated tests.
I needed to tweak the tests/aclocal.in script to avoid passing the
srcdir to -I (which happens if building in srcdir). Otherwise, the
assumptions of the precedence tests in acloca25.test are not respected.
* NEWS: Document new behavior.
* aclocal.in (parse_arguments): Parse ACLOCAL_PATH as a colon-separated
list of directories to be included in the search path.
* doc/automake.texi (Macro Search Path): Document new behavior and
the precedence rules for various elements of the search path.
* tests/Makefile.am (TESTS): Add new testcases.
* tests/acloca24.test: New testcase.
* tests/acloca25.test: New testcase.
* tests/aclocal.in: Special-case in-srcdir build, so that -I is not used
if it brings in unwanted m4 files.
This patch is OK. I've committed it locally to a new branch based off
maint (but the change is intended for master only of course), and can
push it for you when we've dealt with the other ones. (Ping me if you'd
like write access to automake.git, AFAICS you don't have that ATM.)
Thanks,
Ralf
Re: [PATCH] {master} Deprecate obsoleted macro AM_WITH_REGEX.
On Saturday 13 November 2010, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Sat, Nov 13, 2010 at 12:32:49PM CET:
* m4/regex.m4: Document the `AM_WITH_REGEX' macro as obsoleted,
I think technically obsolete is right here, without trailing d.
OK. All instances fixed.
and tell that it should be removed two years from now.
s/tell/state/
Fixed.
(AM_WITH_REGEX): Raise an m4-time warning of the obsolete
category when this macro is used.
* doc/automake.texi (Public Macros): Move description of
`AM_WITH_REGEX' from here ...
(Private Macros): ... to here, and declare it as obsoleted and
Did you mean (Obsolete Macros) here?
Yes, sorry.
to be removed in a future version.
* tests/regex-obsolete.test: New test.
That file is missing from the patch.
Hmpf, forgotten `git add'. Sorry for the slopppiness.
Please resend and I'll finish the review.
* tests/Makefile.am (TESTS): Update.
+...@item AM_WITH_REGEX
+...@acindex AM_WITH_REGEX
+...@vindex WITH_REGEX
+...@opindex --with-regex
+...@cindex regex package
+...@cindex rx package
+Adds @option{--with-regex} to the @command{configure} command line. If
+specified (the default), then the @samp{regex} regular expression
+library is used, @file{regex.o} is put into @code{LIBOBJS}, and
+...@code{with_regex} is defined. If @option{--without-regex} is given,
then
+the @code{rx} regular expression library is used, and @file{rx.o} is put
+into @code{LIBOBJS}. This macro is obsolete now (since rx doesn't seem
+to be maintained), and will be removed in a future version of Automake.
Is rx a package? Where did you find traces to it?
There was this in automake.texi:
@cindex rx package
Also, older comments in m4/regex.m4 read:
# FIXME: This macro seems quite obsolete now since rx doesn't seem to
# be maintained, while regex is.
But I agree that the warning in AM_WITH_REGEX could be simplified to:
$0 is obsolete, since `rx' is unmantained now
That's what I've done in the attached amended patch.
How about adding Consider using gnulib if you need regex
functionality.?
OK, done.
Thanks,
Stefano
From 37b0aeedba10f06a079228a576a813536d188108 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sat, 13 Nov 2010 12:21:28 +0100
Subject: [PATCH] Deprecate obsolete macro AM_WITH_REGEX.
* m4/regex.m4: Document the `AM_WITH_REGEX' macro as obsolete,
and state that it should be removed two years from now.
(AM_WITH_REGEX): Raise an m4-time warning of the obsolete
category when this macro is used.
* doc/automake.texi (Public Macros): Move description of
`AM_WITH_REGEX' from here ...
(Obsolete Macros): ... to here, and declare it as obsolete
and to be removed in a future version.
* tests/regex-obsolete.test: New test.
* tests/Makefile.am (TESTS): Update.
---
ChangeLog | 14 ++
doc/automake.texi | 28 +++-
m4/regex.m4 | 12 +++-
tests/Makefile.am |1 +
tests/Makefile.in |1 +
tests/regex-obsolete.test | 32
6 files changed, 70 insertions(+), 18 deletions(-)
create mode 100755 tests/regex-obsolete.test
diff --git a/ChangeLog b/ChangeLog
index 24b20ae..2091761 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2010-11-13 Stefano Lattarini stefano.lattar...@gmail.com
+
+ Deprecate obsolete macro AM_WITH_REGEX.
+ * m4/regex.m4: Document the `AM_WITH_REGEX' macro as obsolete,
+ and state that it should be removed two years from now.
+ (AM_WITH_REGEX): Raise an m4-time warning of the obsolete
+ category when this macro is used.
+ * doc/automake.texi (Public Macros): Move description of
+ `AM_WITH_REGEX' from here ...
+ (Obsolete Macros): ... to here, and declare it as obsolete
+ and to be removed in a future version.
+ * tests/regex-obsolete.test: New test.
+ * tests/Makefile.am (TESTS): Update.
+
2010-11-08 Stefano Lattarini stefano.lattar...@gmail.com
Improve and extend tests on man pages support.
diff --git a/doc/automake.texi b/doc/automake.texi
index 5ae565c..c4a1902 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3921,19 +3921,6 @@ Add support for the @uref{http://dmalloc.com/, Dmalloc package}. If
the user runs @command{configure} with @option{--with-dmalloc}, then
define @code{WITH_DMALLOC} and add @option{-ldmalloc} to @code{LIBS}.
-...@item AM_WITH_REGEX
-...@acindex AM_WITH_REGEX
-...@vindex WITH_REGEX
-...@opindex --with-regex
-...@cindex regex package
-...@cindex rx package
-Adds @option{--with-regex} to the @command{configure} command line. If
-specified (the default), then the @samp{regex} regular expression
-library is used, @file{regex.o} is put into @code{LIBOBJS}, and
-...@code{with_regex} is defined. If @option{--without-regex} is given, then
-the @code{rx} regular expression library is used, and @file{rx.o} is put
-into @code{LIBOBJS}.
-
@end table
@@ -4009,6 +3996,21 @@ system.
Re: [PATCH] {master} Deprecate obsoleted macro AM_WITH_REGEX.
* Stefano Lattarini wrote on Sat, Nov 13, 2010 at 01:39:04PM CET: On Saturday 13 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sat, Nov 13, 2010 at 12:32:49PM CET: Is rx a package? Where did you find traces to it? There was this in automake.texi: @cindex rx package Also, older comments in m4/regex.m4 read: # FIXME: This macro seems quite obsolete now since rx doesn't seem to # be maintained, while regex is. But I agree that the warning in AM_WITH_REGEX could be simplified to: $0 is obsolete, since `rx' is unmantained now That's what I've done in the attached amended patch. Cool. Thanks for digging. Patch is OK for master. Thanks! Ralf
Re: User extensions
On Mon, Nov 01, 2010 at 08:18:44PM +0100, Ralf Wildenhues wrote: Ideally, I would like to see testsuite coverage for each code path (branch coverage) for new code. I understand that only Stefano is able to produce this in reasonable amount of time, so whatever you guys can manage is better than nothing. Hi, not having followed the code discussion very closely (just hoping it will be in git, soon, so I can start using it, as I have been waiting for something like this for a long time), I just wonder what you mean by branch coverage. If this is execution graph node coverage, then I agree, but if you mean edge coverage, I don't know how you want to achieve this. Any O(x) where x1 algorithm anywhere in the code makes it impossible. If I'm wrong, I'd like to know how Stefano produces it. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: [PATCH] {master} Deprecate obsoleted macro AM_WITH_REGEX.
On Saturday 13 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sat, Nov 13, 2010 at 01:39:04PM CET: On Saturday 13 November 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Sat, Nov 13, 2010 at 12:32:49PM CET: Is rx a package? Where did you find traces to it? There was this in automake.texi: @cindex rx package Also, older comments in m4/regex.m4 read: # FIXME: This macro seems quite obsolete now since rx doesn't seem to # be maintained, while regex is. But I agree that the warning in AM_WITH_REGEX could be simplified to: $0 is obsolete, since `rx' is unmantained now That's what I've done in the attached amended patch. Cool. Thanks for digging. Patch is OK for master. Patch applied, and pushed. Thanks, Stefano
Re: How to structure a GNU scientific project
Hello Luke, you somehow managed to send mail to the automake list without the list address in Cc:, let's fix that. * Luke wrote on Mon, Nov 08, 2010 at 07:36:13PM CET: I'm trying to organize the directory and file structure of my project and figure out how everything should be installed in a way that complies with the GCS and FHS. Currently, my project provides several command line binary executables that do some numerical number crunching using GNU GSL. The inputs to these binaries are a few human readable text files which specify some simulation parameters and settings. The outputs of the executables are a couple of data files (time histories, level curves, etc.) and a couple of text files that show the simulation settings that were actually used and specify the format of the output data. On top of this, I have some Python scripts which generate plots from the data files, and save them as pdfs. The python scripts call os.system to specify the simulation inputs, run the simulation, and process output data to make some plots. It also takes all inputs and outputs (input text files + output data + plots) and bundles them into a time-stamped tar.gz file so that multiple simulation runs don't overwrite each other, and to provide a way to go back and look at simulation results and know exactly what conditions created them. I have several sets of example input text files that allow a user to run the simulations with some default parameters. I'm not clear on where these files should be placed in the source distribution and where they should be installed during 'make install'. I would like a user to be able to easily find and open these text files so they can use them as templates for running simulations with different parameters. My questions are: 1) Where should I put these text simulation configuration files within my source distribution, Whereever they suit you best. There is no standard requirement for this. It is often helpful to have at least a similar directory structure in the source tree than in the install tree (e.g., for the subtree of all configuration files and directories). and where should they be installed to by default? We put them below $(pkgdatadir), if they are system-independent: examplesdir = $(pkgdatadir)/examples examples_DATA = ... Read-only configuration files for programs pertaining to a single system can go in sysconfdir ($(prefix)/etc by default), but that is not typically useful for simulation configuration files. 2) How should I make my application and/or user aware of where they are installed? The way these files are used is by specifying a command line flag that directs the executable to parse a particular input file, so in order for this to be useful, the directory they are installed into must be known. See 'info Autoconf Defining Directories' for how to pass configure information to your code. It is very useful to be able to override the location with a command-line option, so that you can test programs in your test suite before they are installed. 3) Should the python scripts go in site-packages, or would it make more sense for them to be installed alongside the binary executables? Are they programs that are independently useful on their own, i.e., may be called by the user, or just invoked from within your code? If the former, I'd make them bin_SCRIPTS (so ending up in $(bindir)), otherwise I guess it might depend. Auxiliary programs usually go in libexecdir, python modules in the python tree. The python documentation might have more suggestions here. 4) I use the python scripts to save everything in a results/ folder (and I'm often working with my source directory, so this is src/results). It seems like this folder ought to be in the users home directory somewhere, but maybe there are other places it would make sense to put this type of output data? Output should IMVHO generally be relative to the current working directory, and be configurable by either a command-line option, and/or a setting in the configuration files. The user should be able to run multiple instances of your programs concurrently without having to worry about them overwriting each others results. In case you worry about MPI, nowadays I don't know of any startup mechanisms any more that don't allow you to specify the working directory of the running code. It seems like the text input files should go in a subdirectory of /usr/local/share, or maybe the whole project should go into a subdirectory of /opt. Leave that to the user to decide. Without configure switches, prefix will default to /usr/local, thus datarootdir to /usr/local/share, thus datadir to /usr/local/share, thus pkgdatadir to /usr/local/share/$PACKAGE. Each level can be overridden, so './configure --prefix=/opt' will install everything below /opt. The unprivileged user should be able to install below her $HOME with './configure --prefix=$HOME/local' or so.
Re: User extensions
On Mon, Nov 01, 2010 at 08:18:44PM +0100, Ralf Wildenhues wrote: Ideally, I would like to see testsuite coverage for each code path (branch coverage) for new code. I understand that only Stefano is able to produce this in reasonable amount of time, so whatever you guys can manage is better than nothing. Hi, not having followed the code discussion very closely (just hoping it will be in git, soon, so I can start using it, as I have been waiting for something like this for a long time), I just wonder what you mean by branch coverage. If this is execution graph node coverage, then I agree, but if you mean edge coverage, I don't know how you want to achieve this. Any O(x) where x1 algorithm anywhere in the code makes it impossible. If I'm wrong, I'd like to know how Stefano produces it. -- Pippijn van Steenhoven signature.asc Description: Digital signature
ACLOCAL best practice
Hello,
We use ACLOCAL_FLAGS in the GNOME project to specify the include
directories for when we are installing into unusual prefixes.
For example, say I have a GNOME setup in /home/desrt/local.
If I install glib, it includes gsettings.m4 which gets installed
into /home/desrt/local/share/aclocal/. So my ACLOCAL_FLAGS contains
ACLOCAL_FLAGS=-I /home/desrt/local/share/aclocal
and all GNOME packages pick this up (usually by explicit referencing of
this variable from our autogen.sh and Makefile.am).
(for example)
$ACLOCAL $ACLOCAL_FLAGS || exit $?
and
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
I recently filed a bug against a freedesktop.org component because it
didn't honour the ACLOCAL_FLAGS environment variable. That bug got
closed, telling me to use ACLOCAL like so:
ACLOCAL='aclocal -I /home/desrt/local/share/aclocal
which makes a lot of sense and is actually nicer, since the autotools
themselves pick this up.
The problem with this approach is that some of our modules explicitly
invoke a particular version of automake. Consider for example that we
have automake 1.11 as the default (as installed in /usr/bin/automake)
but a project wants to run automake-1.9 from it's autogen.sh script.
At the same time, this project would want to run ${ACLOCAL} in order to
ensure that it picked up the proper include path from that environment
variable -- which would get it aclocal-1.11 (via /usr/bin/aclocal).
What is the best practice here?
In my opinion, this is an argument for why ACLOCAL_FLAGS (or at least
some ACLOCAL_PATH) environment variable is a good idea; anything that
avoids also specifying the name of the binary at the same time. I think
this ought to be supported in an official way within the autotools. I'm
willing to write a patch if people believe it to be a good idea.
Cheers
Re: ACLOCAL best practice
On Saturday 13 November 2010, Ryan Lortie wrote: Hello, Hello Ryan. Just a quick partial reply ... [CUT] In my opinion, this is an argument for why ACLOCAL_FLAGS (or at least some ACLOCAL_PATH environment variable) Supporting ACLOCAL_PATH is a good idea IMO -- and the nice thing about it is that there's already a patch (currently under reviewed) implementing it: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html It will probably be included in the next automake version (1.12). environment variable is a good idea; anything that avoids also specifying the name of the binary at the same time. I think this ought to be supported in an official way within the autotools. I'm willing to write a patch if people believe it to be a good idea. If ACLOCAL_PATH is enough for your needs, that shouldn't be necessary, since someone else has alredy done the work (kudos to Paolo Bonzini). HTH, Stefano
builddir
Hi, In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only.
