I just realized that when I commit changes,
I may commit the bad maintainer-mode files
that I've created but which do not work (for me,
at least). Then when you update, you might
be getting bad files (e.g., configure, aclocal.m4).
I'm not sure what the danger is here in terms of
my overwriting files that will set back your work.
Please send me a list of files that I should remove
from my working directory before I execute a commit.
Perhaps there are none, but I just want to be sure.
P.S. The reason I'm bringing this up is because
I just commited a bunch of files. So we'll soon see
if this is a problem!
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm still investigating, but you're probably correct that the problem is buried somewhere in autoconf, or actually the m4 macro libraries that come with that and libtool. There have been some recent modifications in dealing with 'sed'. So what happened earlier is that your 'autoconf' regenerated 'libtool', but without the 'sed' checking that usually occurs.
Your most recent commit made changes to aclocal.m4, which is essentially the local NCO library of m4 macros that autotools uses when regenerating various files. It looks like a lot of the 'sed' checking I was talking about is gone, as well as some other small refinements. We'll probably want to go back a revision on aclocal.m4, but I'd like to nail down the problem and how to fix it before I take any action like that. However, I still get a fine linux build out of the current CVS.
I usually use 'make maintainer-clean'. However, that won't stop changes to configure, aclocal.m4, etc. since those are maintainer-generated files.
I'll let you know when I have something.
rorik
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your problems with --enable-maintainer-mode still might be 'sed'-related, and there is a new macro LT_AC_PROG_SED that deals with how different sed's work. I think your version of libtool.m4 (which comes with libtool) is missing this macro as well as some other fixes. After touching configure.in in maintainer-mode, aclocal will be run again, and it rewrites aclocal.in with its cache of m4 macros. The libtool.m4 macro is somewhere like
/usr/share/aclocal/libtool.m4
Apparently AC_PROG_SED will be included in newer version of autoconf, but it is not there is 2.53.
I can reproduce your problem if I run 'autoconf;make' using the current CVS snapshot with the aclocal.in you accidentally commited yesterday. Autoconf uses the macros in aclocal to rewrite configure.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am happy to upgrade libtool. Unfortunately,
here is no RPM that has a version of libtool more recent than the one I already have installed. So I CVS co'd the 1.4 branch from GNU, resulting in
which is I believe the same version you have.
Unfortunately, I run into the same problem when
I enable-maintainer-mode. It is difficult for me to
tell whether the newer libtool is actually being
used in maintainer-mode, but I believe it should
be as my paths are set correctly. The only
indication of trouble that I see are these warnings
that I mentioned earlier:
zender@dust:~/nco$ make clean
cd . && /bin/sh /home/zender/nco/autobld/missing --run aclocal-1.6
cd . && \
/bin/sh /home/zender/nco/autobld/missing --run automake-1.6 --foreign --ignore-deps Makefile
cd . && /bin/sh /home/zender/nco/autobld/missing --run autoconf
NONE:0: /usr/bin/m4: `syncoutput' from frozen file not found in builtin table!
NONE:0: /usr/bin/m4: `changesyntax' from frozen file not found in builtin table!
/bin/sh ./config.status --recheck
running /bin/sh ./configure --enable-maintainer-mode --prefix=/home/zender --bindir=/home/zender/bin/LINUX --datadir=/home/zender/nco/data --libdir=/home/zender/lib/LINUX --mandir=/home/zender/nco/man NETCDF_INC=/usr/local/include NETCDF_LIB=/usr/local/lib --no-create --no-recursion
Maybe the problem is with my m4 installation?
Anyway, the results of my recent attempt are on
the ftp site if you care to take a look at the
i686-pc-linux-gnu files.
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Charlie,
Hmm. The m4 error is curious and I'm not too sure what is causing it. However, by looking at the latest version of 'libtool' that was generated, I am pretty sure that your 'aclocal' is still not using the correct libtool.m4 macro. There is a good chance that your newest version of libtool.m4 got placed somewhere in /usr/local/ since that is where libtool got installed. However, the 'aclocal' you get via rpm is probably installed in /usr/bin, which means it probably looks for macros in /usr/share/aclocal/, which is still the old version of libtool.m4. The new version is probably in /usr/local/share/aclocal.
However, I have not been able to rationalize the m4 error, but m4 hasn't really changed much recently. You could try running autoconf on a fresh CVS snapshot (i.e. before your aclocal gets a hold of it) and see if the m4 errors still occur.) However, --enable-maintainer-mode looks like it will continue to fail for you until the new version of libtool.m4 gets included by 'aclocal'.
On another note: I changed the --enable-dods stuff so those libraries don't get linked in unless it is actually dods-enabled. This should fix that MacOSX issue in configure.eg.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found this message by searching google,
it seems that mixing and matching autoconf and m4
has led to the m4 problem. I'm not sure I'll be able
to fix the problem, but now I know how to try.
Charlie
Gary V. Vaughan gary@gnu.org
Tue, 11 Sep 2001 19:47:22 +0100
* Previous message: GNU m4 (Re: AC_TRY_DLOPEN_SELF bug in 1.4.2 again!)
* Next message: AC_TRY_DLOPEN_SELF bug in 1.4.2 again!
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Sep 11, 2001 at 02:30:24PM +0200, Alexander Mai wrote:
>
> ./CVSMake running in /home/mai/compile/lesstif/lesstif
> Running on:
> Linux 2.2.16-SMP #1 SMP Fri Jul 7 21:19:30 CEST 2000 alpha
> Using:
> Autoconf version 2.13
> automake (GNU automake) 1.5
> ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)
>
> running libtoolize
> running aclocal
> running autoconf
> NONE:0: /home/mai/bin/m4: `syncoutput' from frozen file not found in builtin table!
> NONE:0: /home/mai/bin/m4: `changesyntax' from frozen file not found in builtin table!
> NONE:0: /home/mai/bin/m4: `symbols' from frozen file not found in builtin table!
> running autoheader
> NONE:0: /home/mai/bin/m4: `syncoutput' from frozen file not found in builtin table!
> NONE:0: /home/mai/bin/m4: `changesyntax' from frozen file not found in builtin table!
> NONE:0: /home/mai/bin/m4: `symbols' from frozen file not found in builtin table!
>
> The autoconf warnings(!) are independent of libtool 1.4.1 vs. 1.4.2.
>
> Are my problems on that machine all triggered by broken m4 processors!?
Nup. You built Autoconf with m4-1.4o, which generated frozen files
(basically a state dump of M4's memory to speed up macro loading)
dependant on the m4-1.4o symbols. You then downgraded to m4-1.4 which
is missing the functions behind the additional symbols added between
1.4 and 1.4o.
If you rebuild Autoconf with m4-1.4, and reinstall, these errors will
vanish...
Hi Rorik,
I just realized that when I commit changes,
I may commit the bad maintainer-mode files
that I've created but which do not work (for me,
at least). Then when you update, you might
be getting bad files (e.g., configure, aclocal.m4).
I'm not sure what the danger is here in terms of
my overwriting files that will set back your work.
Please send me a list of files that I should remove
from my working directory before I execute a commit.
Perhaps there are none, but I just want to be sure.
P.S. The reason I'm bringing this up is because
I just commited a bunch of files. So we'll soon see
if this is a problem!
Thanks,
Charlie
I'm still investigating, but you're probably correct that the problem is buried somewhere in autoconf, or actually the m4 macro libraries that come with that and libtool. There have been some recent modifications in dealing with 'sed'. So what happened earlier is that your 'autoconf' regenerated 'libtool', but without the 'sed' checking that usually occurs.
Your most recent commit made changes to aclocal.m4, which is essentially the local NCO library of m4 macros that autotools uses when regenerating various files. It looks like a lot of the 'sed' checking I was talking about is gone, as well as some other small refinements. We'll probably want to go back a revision on aclocal.m4, but I'd like to nail down the problem and how to fix it before I take any action like that. However, I still get a fine linux build out of the current CVS.
I usually use 'make maintainer-clean'. However, that won't stop changes to configure, aclocal.m4, etc. since those are maintainer-generated files.
I'll let you know when I have something.
rorik
rorik
Charlie,
Check your version of libtool
rorik@chabuku:~$ libtool --version
ltmain.sh (GNU libtool) 1.4.2a (1.922.2.100 2002/06/26 07:25:14)
Your problems with --enable-maintainer-mode still might be 'sed'-related, and there is a new macro LT_AC_PROG_SED that deals with how different sed's work. I think your version of libtool.m4 (which comes with libtool) is missing this macro as well as some other fixes. After touching configure.in in maintainer-mode, aclocal will be run again, and it rewrites aclocal.in with its cache of m4 macros. The libtool.m4 macro is somewhere like
/usr/share/aclocal/libtool.m4
rorik@chabuku:/usr/share/aclocal$ egrep LT_AC_PROG_SED *.m4
libtool.m4:AC_REQUIRE([LT_AC_PROG_SED])dnl
libtool.m4:# LT_AC_PROG_SED
libtool.m4:AC_DEFUN([LT_AC_PROG_SED],
Apparently AC_PROG_SED will be included in newer version of autoconf, but it is not there is 2.53.
I can reproduce your problem if I run 'autoconf;make' using the current CVS snapshot with the aclocal.in you accidentally commited yesterday. Autoconf uses the macros in aclocal to rewrite configure.
rorik
Hi Rorik,
I am happy to upgrade libtool. Unfortunately,
here is no RPM that has a version of libtool more recent than the one I already have installed. So I CVS co'd the 1.4 branch from GNU, resulting in
zender@dust:~$ which libtool
/usr/local/bin/libtool
zender@dust:~$ /usr/local/bin/libtool --version
ltmain.sh (GNU libtool) 1.4.2a (1.922.2.100 2002/06/26 07:25:14)
which is I believe the same version you have.
Unfortunately, I run into the same problem when
I enable-maintainer-mode. It is difficult for me to
tell whether the newer libtool is actually being
used in maintainer-mode, but I believe it should
be as my paths are set correctly. The only
indication of trouble that I see are these warnings
that I mentioned earlier:
zender@dust:~/nco$ make clean
cd . && /bin/sh /home/zender/nco/autobld/missing --run aclocal-1.6
cd . && \ /bin/sh /home/zender/nco/autobld/missing --run automake-1.6 --foreign --ignore-deps Makefile
cd . && /bin/sh /home/zender/nco/autobld/missing --run autoconf
NONE:0: /usr/bin/m4: `syncoutput' from frozen file not found in builtin table!
NONE:0: /usr/bin/m4: `changesyntax' from frozen file not found in builtin table!
/bin/sh ./config.status --recheck
running /bin/sh ./configure --enable-maintainer-mode --prefix=/home/zender --bindir=/home/zender/bin/LINUX --datadir=/home/zender/nco/data --libdir=/home/zender/lib/LINUX --mandir=/home/zender/nco/man NETCDF_INC=/usr/local/include NETCDF_LIB=/usr/local/lib --no-create --no-recursion
Maybe the problem is with my m4 installation?
Anyway, the results of my recent attempt are on
the ftp site if you care to take a look at the
i686-pc-linux-gnu files.
Thanks,
Charlie
Charlie,
Hmm. The m4 error is curious and I'm not too sure what is causing it. However, by looking at the latest version of 'libtool' that was generated, I am pretty sure that your 'aclocal' is still not using the correct libtool.m4 macro. There is a good chance that your newest version of libtool.m4 got placed somewhere in /usr/local/ since that is where libtool got installed. However, the 'aclocal' you get via rpm is probably installed in /usr/bin, which means it probably looks for macros in /usr/share/aclocal/, which is still the old version of libtool.m4. The new version is probably in /usr/local/share/aclocal.
However, I have not been able to rationalize the m4 error, but m4 hasn't really changed much recently. You could try running autoconf on a fresh CVS snapshot (i.e. before your aclocal gets a hold of it) and see if the m4 errors still occur.) However, --enable-maintainer-mode looks like it will continue to fail for you until the new version of libtool.m4 gets included by 'aclocal'.
On another note: I changed the --enable-dods stuff so those libraries don't get linked in unless it is actually dods-enabled. This should fix that MacOSX issue in configure.eg.
rorik
Hi Rorik,
I found this message by searching google,
it seems that mixing and matching autoconf and m4
has led to the m4 problem. I'm not sure I'll be able
to fix the problem, but now I know how to try.
Charlie
Gary V. Vaughan gary@gnu.org
Tue, 11 Sep 2001 19:47:22 +0100
* Previous message: GNU m4 (Re: AC_TRY_DLOPEN_SELF bug in 1.4.2 again!)
* Next message: AC_TRY_DLOPEN_SELF bug in 1.4.2 again!
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Sep 11, 2001 at 02:30:24PM +0200, Alexander Mai wrote:
>
> ./CVSMake running in /home/mai/compile/lesstif/lesstif
> Running on:
> Linux 2.2.16-SMP #1 SMP Fri Jul 7 21:19:30 CEST 2000 alpha
> Using:
> Autoconf version 2.13
> automake (GNU automake) 1.5
> ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)
>
> running libtoolize
> running aclocal
> running autoconf
> NONE:0: /home/mai/bin/m4: `syncoutput' from frozen file not found in builtin table!
> NONE:0: /home/mai/bin/m4: `changesyntax' from frozen file not found in builtin table!
> NONE:0: /home/mai/bin/m4: `symbols' from frozen file not found in builtin table!
> running autoheader
> NONE:0: /home/mai/bin/m4: `syncoutput' from frozen file not found in builtin table!
> NONE:0: /home/mai/bin/m4: `changesyntax' from frozen file not found in builtin table!
> NONE:0: /home/mai/bin/m4: `symbols' from frozen file not found in builtin table!
>
> The autoconf warnings(!) are independent of libtool 1.4.1 vs. 1.4.2.
>
> Are my problems on that machine all triggered by broken m4 processors!?
Nup. You built Autoconf with m4-1.4o, which generated frozen files
(basically a state dump of M4's memory to speed up macro loading)
dependant on the m4-1.4o symbols. You then downgraded to m4-1.4 which
is missing the functions behind the additional symbols added between
1.4 and 1.4o.
If you rebuild Autoconf with m4-1.4, and reinstall, these errors will
vanish...
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())____
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/