Is this a bug in autoheader?
I am having trouble with the following autoconf test. I am running autoconf 2.14 (from the CVS yesterday). dnl Check for broken USHRT_MAX (under Mingwin and maybe some other systems) AC_CACHE_CHECK(for broken ushrt_max, jikes_cv_ushrt_max_is_broken, AC_TRY_COMPILE([ #include #if ! (USHRT_MAX == 0x) int hi=0; #endif ],[return 0;], jikes_cv_ushrt_max_is_broken=yes , jikes_cv_ushrt_max_is_broken=no) ) if test "$jikes_cv_ushrt_max_is_broken" = "yes" ; then AC_DEFINE(HAVE_BROKEN_USHRT_MAX) fi autoheader does not seem to pick up this HAVE statement. % autoheader % grep BROKEN config.h.in But if I make the following change. --- configure.in2000/04/17 19:13:40 1.3 +++ configure.in2000/04/17 19:42:01 @@ -98,7 +98,7 @@ jikes_cv_ushrt_max_is_broken=no) ) if test "$jikes_cv_ushrt_max_is_broken" = "yes" ; then -AC_DEFINE(BROKEN_USHRT_MAX) +AC_DEFINE(HAVE_BROKEN_USHRT_MAX, , [known to be broken on mingwin beta 20]) fi Then autoheader does "see" the HAVE_BROKEN_USHRT_MAX symbol. % autoheader % grep BROKEN config.h.in #undef HAVE_BROKEN_USHRT_MAX What's the deal? is this a bug in autoheader or what? The autoconf docs do not seem to say anything about this. Mo Dejong Red Hat Inc.
Is this a bug in autoconf?
I want to set up my project so that I can cross compile, and I thought autoconf would help me do that. I put the AC_CANONICAL_HOST macro at the top of my configure.in file. I built a cross compiler for cygwin and put it on my path. But when I try to run ./configure with a target argument, it does not use the right compiler. % ../mini/configure --target=i586-cygwin32 checking host system type... i686-pc-linux-gnu checking for c++... c++ After much banging of head on wall, I found this note in the autoconf docs. If you are cross-compiling, you still have to specify the names of the cross-tools you use, in particular the C compiler, on the configure command line, e.g., CC=m68k-coff-gcc configure --target=m68k-coff So I tried that and it seemed to work. % ../mini/configure --target=i586-cygwin32 CXX=i586-cygwin32-c++ checking host system type... i686-pc-linux-gnu checking for c++... i586-cygwin32-c++ checking whether the C++ compiler (i586-cygwin32-c++ ) works... yes My question is, why on earth do I need to give the name of the compiler I want to use in the CC or CXX variable? Why not have autoconf just take the --target argument (i586-cygwin32) and slap a -c++ onto that? Why will autoconf not check for the cross given in the --target argument? Mo Dejong Red Hat Inc.
Re: Is this a bug in autoconf?
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 20, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > But when I try to run ./configure with a target argument, it does not
> > use the right compiler.
>
> --target is used only for compilers, linkers, etc, to specify the
> platform *for which* the programs should generate code. I think what
> you want is to set --host, that specifies the platform on which you
> intend the program to run. I'm not sure this will look for the
> appropriate compilers, though.
>
> > My question is, why on earth do I need to give the name of
> > the compiler I want to use in the CC or CXX variable?
>
> Because autoconf always looks for a C compiler named gcc or cc. When
> it looks for a C compiler, it doesn't even know if it's cross
> compiling; this is only tested after a C program is compiled.
>
> > Why not have autoconf just take the --target argument
> > (i586-cygwin32) and slap a -c++ onto that?
Ok, I can buy that --host argument, but then why does using
--host also not work?
mo(~/foo)% cat configure.in
AC_INIT(foo.cpp)
AC_PREREQ(2.14)
AC_CANONICAL_HOST
AC_LANG_CPLUSPLUS
AC_PROG_CXX
mo(~/foo)% ./configure --host=i586-cygwin32
checking host system type... i586-pc-cygwin32
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
I really need to get a better sig:)
Mo Dejong
Red Hat Inc.
> Seems like a good idea, as long as you replace --target for --host.
>
> --
> Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
> Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
> Free Software Developer and EvangelistCS PhD student at IC-Unicamp
> oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Is this a bug in autoconf?
Ok, lets get that implemented now.
Here is "kind of" what I want to do.
AC_INIT(foo.cpp)
AC_PREREQ(2.14)
cross_host=$host
host=NONE
AC_CANONICAL_HOST
AC_LANG_CPLUSPLUS
if test "$cross_host" != "NONE" && test "$cross_host" != "$host"; then
AC_CHECK_PROGS(CXX, ${cross_host}-c++ ${cross_host}-g++, , ${PATH})
fi
AC_PROG_CXX
That "kind of" works.
mo(~/project/jikes/src/Xcygwin_mini)% ../mini/configure --host=i586-cygwin32
checking host system type... i686-pc-linux-gnu
checking for i586-cygwin32-c++... i586-cygwin32-c++
checking for c++... (cached) i586-cygwin32-c++
checking whether the C++ compiler (i586-cygwin32-c++ ) works...
There are a couple of problems with this approach. It compares the
result of running config.guess to what the user passed in with --host
, but I am not sure we actually want the configure script to
continue to think it is running on a i686-pc-linux-gnu host when
it is actually using a cross compiler.
This is actually a more general problem. For instance, when I run
./configure on a Window box running cygwin but I use a cross like
mingwin, the host still returns cygwin values. If the autoconf
script uses host values to make compile time decisions, then
they will be wrong because we are using a cross compiler.
Here is a quick example from the online autoconf macro archive.
http://peti.cys.de/autoconf-archive/Miscellaneous/acx_check_pathname_style.html
This test will break if you use a cross compiler with cygwin.
So who is at fault here? Should autoconf know about the host
it is running under and the cross "host" info?
Mo Dejong
Red Hat Inc.
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > Ok, I can buy that --host argument, but then why does using
> > --host also not work?
>
> Because that was never implemented?
>
> --
> Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
> Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
> Free Software Developer and EvangelistCS PhD student at IC-Unicamp
> oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>
>
Re: Is this a bug in autoconf?
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > There are a couple of problems with this approach. It compares the
> > result of running config.guess to what the user passed in with
> > --host, but I am not sure we actually want the configure script to
> > continue to think it is running on a i686-pc-linux-gnu host when it
> > is actually using a cross compiler.
Ok, let me see if I have my terms straight here. In my case,
i686-pc-linux-gnu would be my "build" platform and i586-cygwin32
would be my "host" platform.
> configure is run on the *build* platform, so setting host to NONE as
> you do is totally wrong, because it will cause configure to assume
> host and build are the same platform. When the user specifies --host,
> he's explicitly telling configure they're not. What you want to do is
> to compare $host with $build.
>
> > If the autoconf script uses host values to make compile time
> > decisions, then they will be wrong because we are using a cross
> > compiler.
>
> If it uses *host* values, it will be right, because the *host*
> platform is that on which the built program will run. You probably
> mean *build* values here, and then you're right, and it is indeed
> something the developer should worry about.
>
> > http://peti.cys.de/autoconf-archive/Miscellaneous/acx_check_pathname_style.html
>
> > This test will break if you use a cross compiler with cygwin.
>
> No, it is correct, because it decides what pathname style to use
> depending on *host*. If it depended on the *build* platform, it would
> indeed be broken.
>
> > So who is at fault here?
>
> You're just misunderstanding the nomenclature.
>
> > Should autoconf know about the host it is running under and the
> > cross "host" info?
Humm, I have never used this AC_CANONICAL_BUILD macro.
The documentation seems to indicate that the only macro I
would need was AC_CANONICAL_HOST? Are the docs wrong about that?
`AC_CANONICAL_HOST' is all that is
needed for programs that are not part of a compiler tool chain.
No that you mention it, the 2.13 docs do not even mention
AC_CANONICAL_HOST. Was this something that was added recently?
> Yep. That's what AC_CANONICAL_BUILD is for.
So I added AC_CANONICAL_BUILD my configure.in script, removed my hacks
and ran it again. Now I am seeing the following. This has got to
be a bug.
mo(~/foo)% ./configure --host=i586-cygwin32
checking host system type... i586-pc-cygwin32
checking build system type... i586-pc-cygwin32
checking for c++... c++
Mo DeJong
Red Hat Inc.
> --
> Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
> Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
> Free Software Developer and EvangelistCS PhD student at IC-Unicamp
> oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Is this a bug in autoconf? (patch included)
I think I have found the cause of the bug in autoconf. The problem was that the build system was not getting detected properly. Here is an example configure.in that showed the problem. mo(~/foo)% cat configure.in AC_INIT(foo.cpp) AC_PREREQ(2.14) AC_CANONICAL_HOST AC_CANONICAL_BUILD AC_LANG_CPLUSPLUS if test "$host" != "$build" ; then echo "host $host != build $build" fi AC_PROG_CXX When I ran this script it produced the following, which is fine for a native build. mo(~/foo)% ./configure checking host system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for c++... c++ Now when I passed --host, it thought that build and host were the same. mo(~/foo)% ./configure --host=i586-cygwin32 checking host system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for c++... c++ The bug was in acgeneral.m4. I replaced a "host" with $1 and switched the order of the tests so that config.guess gets run when checking host or build types of THINGS. 2000-04-20 Mo DeJong <[EMAIL PROTECTED]> * acgeneral.m4 (AC_CANONICAL_THING): Fixed macro so that config.guess is run for both AC_CANONICAL_HOST and AC_CANONICAL_BUILD. This fixes detection of the diff in host vs build so that cross compiling works properly. Index: acgeneral.m4 === RCS file: /cvs/autoconf/acgeneral.m4,v retrieving revision 1.437 diff -u -r1.437 acgeneral.m4 --- acgeneral.m42000/04/13 08:25:12 1.437 +++ acgeneral.m42000/04/21 09:17:33 @@ -1807,11 +1807,11 @@ NONE) case $nonopt in NONE) -ifelse([$1], [host],[dnl +ifelse([$1], [target], [dnl + ac_cv_$1_alias=[$]$1_alias ;;],[dnl if ac_cv_$1_alias=`$ac_config_guess`; then : else AC_MSG_ERROR(cannot guess $1 type; you must specify one) - fi ;;],[dnl - ac_cv_$1_alias=$host_alias ;; + fi ;; ])dnl *) ac_cv_$1_alias=$nonopt ;; esac ;; Here is the output of my example after the patch. Whoohoo! mo(~/foo)% ./configure --host=i586-cygwin32 checking host system type... i586-pc-cygwin32 checking build system type... i686-pc-linux-gnu host i586-pc-cygwin32 != build i686-pc-linux-gnu checking for c++... c++ Mo Dejong Red Hat Inc.
Re: Is this a bug in autoconf?
On 21 Apr 2000, Alexandre Oliva wrote: > On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > > > The documentation seems to indicate that the only macro I > > would need was AC_CANONICAL_HOST? Are the docs wrong about that? > > You'd seldom need information about the build platform, and you'd only > need information about the target platform when building the > toolchain. > > > No that you mention it, the 2.13 docs do not even mention > > AC_CANONICAL_HOST. Was this something that was added recently? > > No, it's not recent, but I think it was supposed to be something > internal. So if it should have been "internal" then why do I need to add the AC_CANONICAL_BUILD macro to my configure.in file to get cross compiling to work? In looking at the source, I also came across this AC_CHECK_TOOL_PREFIX macro which seems to be doing exactly what I want, running the host and build check and then comparing the host and the build. So it looks like the AC_CHECK_TOOL macro is what I should have been using all along. This minimal configure.in should do this trick. AC_INIT(foo.cpp) AC_PREREQ(2.14) AC_LANG_CPLUSPLUS AC_CHECK_TOOL(CXX, c++) AC_PROG_CXX Problem is, it not seem to work. It looks for the right compiler but it does not actually use it. mo(~/foo)% ./configure --host=i586-cygwin32 checking host system type... i586-pc-cygwin32 checking build system type... i686-pc-linux-gnu checking for i586-cygwin32-c++... c++ checking for c++... (cached) c++ checking whether the C++ compiler (c++ ) works... yes checking whether the C++ compiler (c++ ) is a cross-compiler... no checking whether we are using GNU C++... yes checking whether c++ accepts -g... yes Any ideas? Mo Dejong Red Hat Inc.
Re: Is this a bug in autoconf?
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > So if it should have been "internal" then why do I need to add the
> > AC_CANONICAL_BUILD macro to my configure.in file to get cross
> > compiling to work?
But the docs tell me I only need AC_CANONICAL_SYSTEM if I am
a tool in a cross compiler toolchain. The docs need to be
updated.
> You'd use AC_CANONICAL_SYSTEM.
>
> > In looking at the source, I also came across this AC_CHECK_TOOL_PREFIX
> > macro which seems to be doing exactly what I want, running the
> > host and build check and then comparing the host and the build.
>
> Indeed. Stupid me, this macro didn't occur to me :-(
>
> > Problem is, it not seem to work. It looks for the right compiler
> > but it does not actually use it.
Doh! Sorry about that, I goofed. Cross compiler detection
is now working if I used the AC_CHECK_TOOL(CXX, c++) macro.
mo(~/foo)% ./configure --host=i586-cygwin32
checking host system type... i586-pc-cygwin32
checking build system type... i686-pc-linux-gnu
checking for i586-cygwin32-c++... i586-cygwin32-c++
checking for c++... (cached) i586-cygwin32-c++
later
Mo
> Is CXX set in your environment?
>
> --
> Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
> Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
> Free Software Developer and EvangelistCS PhD student at IC-Unicamp
> oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>
>
Re: Is this a bug in autoconf?
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > On 21 Apr 2000, Alexandre Oliva wrote:
> >> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> >>
> >> > So if it should have been "internal" then why do I need to add the
> >> > AC_CANONICAL_BUILD macro to my configure.in file to get cross
> >> > compiling to work?
>
> > But the docs tell me I only need AC_CANONICAL_SYSTEM if I am
> > a tool in a cross compiler toolchain.
>
> Yep, that's right. The point is that you should seldom need
> information about the build platform. So AC_CANONICAL_SYSTEM, that
> sets build, host and target, is useful for cross-compiler toolchains
> because it sets target, and target is useless for any other kind of
> application.
>
> --
> Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
> Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
> Free Software Developer and EvangelistCS PhD student at IC-Unicamp
> oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
>
Ok, I am starting to see the light now. I now think that I have
a much better way to solve this whole mess. I created a patch
to add a AC_CHECK_TOOLS macro that works just like the AC_CHECK_PROGS
macro. Then I just pop this macro into AC_PROG_CXX and presto
my 4 line script works for the cross compile case.
mo(~/foo)% cat configure.in
AC_INIT(foo.cpp)
AC_PREREQ(2.14)
AC_LANG_CPLUSPLUS
AC_PROG_CXX
mo(~/foo)% ./configure
checking host system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
mo(~/foo)% ./configure --host=i586-cygwin32
checking host system type... i586-pc-cygwin32
checking build system type... i686-pc-linux-gnu
checking for i586-cygwin32-c++... i586-cygwin32-c++
checking whether the C++ compiler (i586-cygwin32-c++ ) works... yes
checking whether the C++ compiler (i586-cygwin32-c++ ) is a
cross-compiler... yes
checking whether we are using GNU C++... yes
checking whether i586-cygwin32-c++ accepts -g... yes
I will send the patch along with my earlier patch to autoconf-patches.
I want to touch it up a bit an make sure it works for C as well.
Mo Dejong
Red Hat Inc.
Re: Is this a bug in autoconf? (patch included)
On 21 Apr 2000, Akim Demaille wrote: > >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: > > Alexandre> Sounds good to me (i.e., you've got one approval; a patch > Alexandre> needs two to be installed in the autoconf CVS tree). > > I confess I'm a bit lost by the change. We're moving from > > ac_cv_host_alias=`$ac_config_guess` > ac_cv_build_alias=$host_alias > ac_cv_target_alias=$host_alias > > to > > ac_cv_host_alias=`$ac_config_guess` > ac_cv_build_alias=`$ac_config_guess` > ac_cv_target_alias=$target_alias The "alias" is the thing that the user could have passed in on the command line. In the case of the host you could pass in i586-cygwin32 and get the target_alias set to that but the target would be i586-pc-cygwin32. > I don't understand why this helps: how can we define target_alias in > terms of ac_cv_target_alias since it appears to me that it is the > converse that happen? See the code: > > | ... > | $1=$ac_cv_$1 > | $1_alias=$ac_cv_$1_alias > | $1_cpu=$ac_cv_$1_cpu > | $1_vendor=$ac_cv_$1_vendor > | $1_os=$ac_cv_$1_os > | ... > | ])# _AC_CANONICAL_THING If the build test was always done then the result of that could be used when figuring out the host. The host would not need to do another config.guess in that case. I hope that helps Mo DeJong Red Hat Inc. > Also, how do we still guarantee a valid default for > ac_cv_target_alias? Why do we need to run twice config.guess instead > of propagating ac_cv_build_alias=$host_alias? > > > Personally, I'd like better that thing to be written with an m4_case, > it is becoming hardly readable. For instance before Mo's patch it > would have been: > > ... > NONE) > m4_case([$1], > [host], > [ac_cv_host_alias=`$ac_config_guess` || >AC_MSG_ERROR(cannot guess host type; you must specify one)], > [target], >[ac_cv_target_alias=$host_alias], > [build], >[ac_cv_build_alias=$host_alias]) > *) ac_cv_$1_alias=$nonopt ;; > ... > > Akim >
Re: Is this a bug in autoconf? (patch included)
I like this idea. I just started trying to use autoconf to do cross
compiles yesterday and I can tell you that it is VERY hard to figure
out which of the AC_CANONICAL_{BUILD, TARGET, HOST, SYSTEM} macros one
should be using. The docs did not help much, there was a cryptic
note about only needing HOST and the docs also said AC_CANONICAL_SYSTEM
would not be needed unless the tool is part of a compiler that was
crossing itself. It would be a lot more simple if we just had on
AC_CANONICAL_SYSTEM macro. That way, the scripts would check
for any of the --target, --host, or --build arguments instead
of the current approach which is to silently fail unless the
BUILD, TARGET, or HOST macro had been run.
Mo Dejong
Red Hat Inc.
> This is why I would like to reiterate a proposal I made: get rid of
> AC_CANONICAL_{BUILD, TARGET, HOST}, and provide only
> AC_CANONICAL_SYSTEM.
>
> I don't think maintainers need to ask themselves the question of which
> of these they should run, I don't think the slight speed improvement
> should be considered. So my proposal is that all these former names
> become just an AC_REQUIRE of AC_CANONICAL_SYSTEM, to be guaranteed to
> remain compatible, and we just document the latter. And we move into
> it the --help portion.
>
> How does it sound?
>
> Akim
Re: Is this a bug in autoconf? (patch included)
On Fri, 21 Apr 2000, Earnie Boyd wrote: > --- Pavel Roskin <[EMAIL PROTECTED]> wrote: > -8<- > > Well, this thread began with a message from Mo DeJong <[EMAIL PROTECTED]> > > (Cygnus dot Com !!!) who tried to use --target where is should have been > > --host. > > > > I wouldn't give too much credance to (Cygnus dot Com), newbies do exist there > too, not that I'm calling Mo DeJong a newbie. I believe Mo came from Red Hat > which now owns Cygnus. Yup, I am a newbie to cross compiling. I just got my first Linux cross cywin build humming the other day and after a long night of patching autoconf, I was able to use ./configure to cross compile. As a "new user", the main thing I can tell you is that the docs for autoconf are rather hard to use. For instance, here is what the autoconf docs say in reguards to cross compiling with autoconf. If the user gives configure a non-option argument, it is used as the default for the host, target, and build system types if the user does not specify them explicitly with options. The target and build types default to the host type if it is given and they are not. If you are cross-compiling, you still have to specify the names of the cross-tools you use, in particular the C compiler, on the configure command line, e.g., CC=m68k-coff-gcc configure --target=m68k-coff See that --target option? If that is not confusing I don't know what is. Mo Dejong Red Hat Inc.
I found cross compiler related bug in autoconf.
There is a problem with the way autoconf tries to detect
if a compiler is in fact a cross compiler. Currently,
autoconf will write out the following program:
#ifdef __cplusplus
extern "C" void exit (int);
#endif
int main(){return(0);}
If this program compiles that autoconf sets the
ac_cv_prog_cxx_works var to "yes" and tries
to run it.
if (./conftest; exit) 2>/dev/null; then
ac_cv_prog_cxx_cross=no
else
ac_cv_prog_cxx_cross=yes
fi
If the program can not be run, autoconf assumes
that the compiler is a cross compiler. This
approach has a some serious problems. If the
program can be compiled and linked but
it does not run because of some problem
with the runtime linker, then autoconf
will think that the compiler is a cross
compiler.
Here is the output I got when tring to run
this on a Solaris box with g++ and autoconf 2.14.
$ ./configure
checking host system type... sparc-sun-solaris2.7
checking build system type... sparc-sun-solaris2.7
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... yes
checking whether we are using GNU C++... yes
...
checking whether byte ordering is bigendian... configure: error: cannot run
test program while cross compiling
What is really going wrong here is that the ./conftest
executable can not be run on the system because or a
problem with the LD_LIBRARY_PATH. If you try it from
the command line you get the following. In this case,
the /usr/local/lib dir does not appear on the rld path.
% c++ a.C
% ./a.out
ld.so.1: ./a.out: fatal: libstdc++.so.2.10.0: open failed: No such file or directory
Killed
I guess one could make the argument that the AC_C_BIGENDIAN macro
inside aclang.m4 could be improved to account for the cross compiler
case, but the real problem is the way autoconf tries to detect
the cross compiler case.
To really fix this problem I suggest that we add an extra check
to make sure the host is not the same as the build. This of
course assumes that my earlier patch to actually set host and
build correctly has been applied.
Index: acgeneral.m4
===
RCS file: /cvs/autoconf/acgeneral.m4,v
retrieving revision 1.437
diff -u -r1.437 acgeneral.m4
--- acgeneral.m42000/04/13 08:25:12 1.437
+++ acgeneral.m42000/04/24 08:00:25
@@ -2609,7 +2622,7 @@
# If we can't run a trivial program, we are probably using a cross compiler.
if (./conftest; exit) 2>/dev/null; then
[$3]=no
- else
+ elif test $host != $build; then
[$3]=yes
fi],
[[$2]=no])[]dnl
This test would only be run if running the ./conftest executable failed.
If folks think this is a good idea I can send it to autoconf-patches.
As a more general question, is it really a good idea to redirect
the error output to /dev/null when running a test program like this?
Why not write the output to the log file. That would make it a lot
easier to debug this sort of problem because the rld errors would
show up in the log file.
thanks
Mo DeJong
Red Hat Inc.
Re: I found cross compiler related bug in autoconf.
On Mon, 24 Apr 2000, Pavel Roskin wrote: > Hello! > > > If the program can not be run, autoconf assumes that the compiler is a > > cross compiler. This approach has a some serious problems. If the > > program can be compiled and linked but it does not run because of some > > problem with the runtime linker, then autoconf will think that the > > compiler is a cross compiler. But the system I was trying to compile on should have worked if not for a misconfiguration. I was not actually trying to cross compile but the autoconf generated script thought that I was. If the program will not run because of a problem with the runtime linker, we should not just assume that the program is being cross compiled. > I think that it's not a bug, this is a definition of cross-compiling. > If you compiling on a broken system but you expect the resulting > executable to run on a "good" system, you are cross-compiling. > If you are compling on FreeBSD for Linux and you have iBCS with Linux > emulation, you are not cross-compiling. > > Essentially, if you are cross-compiling, you cannot and should not run > executables produced by the build process on the machine doing the > build. Then AC_C_BIGENDIAN is also broken. It should not error out like this for the cross compile case. checking whether byte ordering is bigendian... configure: error: cannot run test program while cross compiling > Autoconf is consistent in this definition. Tests that require compiled > programs to be executed are not run as long as a trivial program fails to > run. > > Regards, > Pavel Roskin Mo DeJong Red Hat Inc.
Re: autoheader question
Perhaps this is a stupid question, but did you remember to add the following to the top of your configure.in file? I made a simmilar mistake when writing my configure.in. AC_CONFIG_HEADER(config.h) Mo Dejong Red Hat Inc. On Tue, 25 Apr 2000, Lars Hecking wrote: > > $ autoheader --version > Autoconf version 2.13 > > One thing I can't seem to figure out: if acconfig.h exists, is > autoheader supposed to add all its contents to config.h.in? And > if this doesn't happen, is there a way to find out why?
Re: Is this a bug in autoconf? (patch included)
> Peter> If you want to make a change I'd claim that it would be much
> Peter> more logical to get rid of AC_CANONICAL_SYSTEM instead and let
> Peter> people explicitly call CANONICAL_{HOST|BUILD} if they want
> Peter> information about the host or build system, whyever they would
> Peter> need that. It's just as bogus to list --build as an option if
> Peter> you don't actually evaluate it (or don't even care, as is
> Peter> probably the case most of the time).
>
> OK. Actually one of the reason why I was against keeping AC_CAN_HOST
> and AC_CAN_SYS was that it is asymmetrical. But if we keep
> AC_CAN_(HOST, BUILD, TARGET), I'm fine.
Ok, it sounds like the main reason folks want to keep 3 macros
is so that --build is not listed in the --help output unless
the package maintainer wants it used.
I am still confused about what situation would actually
call for AC_CANONICAL_BUILD without also calling
AC_CANONICAL_HOST? Also, wouldn't I always need to call
AC_CANONICAL_BUILD when I was using AC_CANONICAL_HOST?
I was under the impression that the whole point of
the --host flag was to tell autoconf that
$host != $build and is therefore a cross compile.
Why don't we just merge the AC_CANONICAL_BUILD macro
into the AC_CANONICAL_HOST macro and not print out
the --build option. The --host option would still
be used to give the cross triple and the --target
option would not showup in the output unless
AC_CANONICAL_TARGET was used in configure.in.
Mo Dejong
Red Hat Inc.
Re: Is this a bug in autoconf? (patch included)
On Tue, 25 Apr 2000, Pavel Roskin wrote: > Hello! > > On Tue, 25 Apr 2000, Mo DeJong wrote: > > > I am still confused about what situation would actually > > call for AC_CANONICAL_BUILD without also calling > > AC_CANONICAL_HOST? Also, wouldn't I always need to call > > AC_CANONICAL_BUILD when I was using AC_CANONICAL_HOST? > > You need AC_CANONICAL_BUILD when > > 1) You want to figure out specific features of the build system without > actual testing for them. For example, if the actual test requires root > permissions or crashes the OS occasionally, I would prefer to test if the > build is running on BadOS without demonstrating how bad it is. > > 2) You want to encode the build system name somewhere in the program. It > may be nice sometimes just for "management" purposes. > > I don't think AC_CANONICAL_BUILD should be used often. Ok, I see your point about using AC_CANONICAL_BUILD, but is there any reason that someone would want to use AC_CANONICAL_HOST without having it AC_REQUIRE() AC_CANONICAL_BUILD? Mo Dejong Red Hat Inc.
Re: Revamping AC_CANONICAL_*
On 25 Apr 2000, Akim Demaille wrote: > >>>>> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Ian> Dying is definitely wrong. I am also inclined to vote against > Ian> warnings. > > OK, then here is my revamped revamping. It does not include your > suggestion for host != build => cross-compiling yet. I'd rather have > this as a separate patch later, this one is already big enough (just > adding cross_compilation=yes is not right). > > It does everything I said in the message to Tom, i.e.: > > - don't document --target etc. when the AC_CANONICAL_TARGET etc. is not > used > > - change the defaults to > 1. build ?= config.guess > 2. host ?= build > 3. target ?= host Akim, I was with you up until this one. Why would you want to remove the --host option? If I pass --host=CROSS-TRIPLE that should tell the system that the host is different than the build so it is a cross compile, right? > - remove the support of HOST on the command line, because it is > incorrect to map this HOST to a virtual --host=HOST > > Akim Mo Dejong Red Hat Inc.
So it seems like AC_C_BIGENDIAN is broken for cross case
When running a simple configure.in script that uses AC_C_BIGENDIAN I get the following error. checking whether the C++ compiler (i386-mingw32msvc-c++ ) works... yes checking whether the C++ compiler (i386-mingw32msvc-c++ ) is a cross-compiler... yes ... checking whether byte ordering is bigendian... configure: error: cannot run test program while cross compiling It seems clear that the AC_TRY_RUN does not have an argument for the cross compile case. Can we at least get agreement that this AC_C_BIGENDIAN macro is in fact broken? Mo Dejong Red Hat Inc.
Re: So it seems like AC_C_BIGENDIAN is broken for cross case
How would people feel about the following patch? It sort of fixes AC_C_BIGENDIAN in the sense that it no longer errors out. I am not sure how we can detect the system's endian ordering without actually running a program, so this is a tempory suggested fix until a beter one comes along. Index: aclang.m4 === RCS file: /cvs/autoconf/aclang.m4,v retrieving revision 1.6 diff -u -r1.6 aclang.m4 --- aclang.m4 2000/04/11 12:00:13 1.6 +++ aclang.m4 2000/04/26 05:59:47 @@ -1003,7 +1003,7 @@ } u; u.l = 1; exit (u.c[sizeof (long) - 1] == 1); -}], ac_cv_c_bigendian=no, ac_cv_c_bigendian=yes) +}], ac_cv_c_bigendian=no, ac_cv_c_bigendian=yes, ac_cv_c_bigendian=unknown) fi]) if test $ac_cv_c_bigendian = yes; then AC_DEFINE(WORDS_BIGENDIAN, 1, Mo Dejong Red Hat Inc.
Autoconf fails to install without help2man
Why does autoconf require another program to install? This other program is not included in the CVS. The error message seems to indicate that not having the program is not critical ( see the WARNING: message) but the "make install" fails to run without the help2man program. Updating man page autoreconf.1 WARNING: `help2man' is needed, and you do not seem to have it handy on your system. You might have modified some files without having the proper tools for further handling them. Check the `README' file, it often tells you about the needed prerequirements for installing this package. You may also peek at any GNU archive site, in case some other package would contain this missing `help2man' program. make[1]: *** [autoreconf.1] Error 1 make[1]: Leaving directory `/usr/local/project/build/mod_autoconf/man' make: *** [all-recursive] Error 1 I have nothing against this help2man program but it either needs to be included in the CVS and built if not found or just not required during the install step. How should we fix this problem? Mo Dejong Red Hat Inc.
Re: Autoconf fails to install without help2man
On 27 Apr 2000, Akim Demaille wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > Mo> Why does autoconf require another program to install? > > Because you're referring to the CVS tarball, hence you shall be ready > to be in position of a maintainer. Autoconf, once completely packed, > will not require help2man. > > Nevertheless, the CVS repo is keeping all the files up to date, with > all the dependencies satisfied. > > Mo> The error message seems to > Mo> indicate that not having the program is not critical ( see the > Mo> WARNING: message) but the "make install" fails to run without the > Mo> help2man program. > > Apparently you did something, such as modifying autoconf.sh, which > triggered the regeneration of the man pages, so help2man was launched. > Indeed, it is an undesired result that your installation fails, any > patch/analysis will be appreciated :). > > Or else, maybe you're running HP-UX, native make, and you are paying > its weird behavior wrt timestamps :) > > Akim > I have found the reason that "make install" was failing in the case that the help2man program can not be located. The following patch fixes the "missing" script so that it does not return an error condition. The missing porgram should only be a warning and not a compile time error. I have also CCed this to the patch mailing list in the hope that it will make it into the CVS. 2000-04-27 Mo DeJong <[EMAIL PROTECTED]> * missing: Fixed missing script so that it does not return an error condition when a missing program is detected. When a missing program is detected the missing script should print a warning message and return 0. Index: missing === RCS file: /cvs/autoconf/missing,v retrieving revision 1.1 diff -u -r1.1 missing --- missing 1999/10/31 01:54:29 1.1 +++ missing 2000/04/28 09:57:47 @@ -183,7 +183,7 @@ it often tells you about the needed prerequirements for installing this package. You may also peek at any GNU archive site, in case some other package would contain this missing \`$1' program." -exit 1 +exit 0 ;; esac Mo DeJong Red Hat Inc
Re: Revamping AC_CANONICAL_*
I tested out this patch and it seems to be working just fine for me. Here is the output I get. % ~/project/mod_jikes/jikes/src/configure --prefix=/tmp/jikes \ --host=i386-mingw32msvc checking build system type... i686-pc-linux-gnu checking host system type... i386-pc-mingw32msvc checking for c++... c++ ... checking for cygwin_win32_to_posix_path_list... no checking for i386-mingw32msvc-strip... i386-mingw32msvc-strip The first part shows that build and host detection are working and the second part shows that the AC_CHECK_TOOL() macro is correctly detecting the host != $build case and finding i386-mingw32msvc-strip given "strip" as the tool name. Mo Dejong Red Hat Inc. On 26 Apr 2000, Akim Demaille wrote: > >>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: > > Akim> It is Ian who suggested twice that in these conditions, we > Akim> should get rid of HOST as an argument. > > So the proposal below still does this, but it is open to discussion. > > This is a real proposal this time, I think we have reached an > agreement. Remains to check build != host, and the patch from Mo so > that cross compilers are searched for when --host is used. > > Akim > > PS/ There is one thing which might be debatable: I used AC_DEFUN_ONCE > for AC_CANONICAL_BUILD etc. because I think it is right, and it avoids > duplicate --help documentation if for instance AC_A_TARGET is called, > and then AC_C_BUILD. But I know Tom doesn't like AC_DEFUN_ONCE. > > > Index: ChangeLog > === > RCS file: /cvs/autoconf/ChangeLog,v > retrieving revision 1.562 > diff -u -r1.562 ChangeLog > --- ChangeLog 2000/04/20 11:49:53 1.562 > +++ ChangeLog 2000/04/26 10:35:39 > @@ -1,3 +1,54 @@ > +2000-04-26 Akim Demaille <[EMAIL PROTECTED]> > + > + Provide a macro to canonicalize a configuration name. > + Suggested by Ralf Corsepius. > + > + * acgeneral.m4 (AC_CANONICALIZE): New macro. > + (_AC_CANONICAL_THING): Use it. > + > + > + Change the defaults for build, host, and target systems: > + build defaults to `config.guess`. > + host defaults to $build. > + target defaults to $host. > + Suggested by Mo DeJong, Pavel Roskin, Tom Tromey, Ian Lance > + Taylor, and many others. > + > + * acgeneral.m4 (_AC_INIT_PARSE_ARGS): Set `$build', `$host' and > + `$target' to nothing instead of NONE. > + (AC_CANONICAL_SYSTEM): AU_DEFUN'd as `AC_CANONICAL_TARGET'. > + (_AC_CANONICAL_THING): Use an explicit m4_case to set the defaults > + depending upon the THING. > + Implement the default values. > + (AC_CANONICAL_TARGET): Handle the `AC_ARG_PROGRAM' part > + `AC_CANONICAL_SYSTEM' used to provide. > + * doc/autoconf.texi: Adjust. > + > + > + Because of the new defaults, because specifying HOST on the > + command line of `configure' was not the same as passing it to > + `--host', drop the support of HOST as an argument. > + Suggested by Ian Lance Taylor. > + > + * acgeneral.m4 (_AC_INIT_PARSE_ARGS, _AC_CANONICAL_THING): Remove > + the support of `$nonopt'. > + Die when used. > + > + > + Documenting --build, --host and --target when configure does not > + handle them causes confusion. > + Suggested by Pavel Roskin. > + Nevertheless configure must not die on such an `unsupported' > + option: it does happen that people build an entire tree of > + packages, some of them expecting `--host' etc. some others not. > + Stressed by Tom Tromey and Ian Lance Taylor. > + > + * acgeneral.m4 (HELP_CANON): New diversion. > + (_AC_INIT_PARSE_ARGS): Don't document these options. > + (AC_CANONICAL_BUILD, AC_CANONICAL_HOST, AC_CANONICAL_TARGET): > + Document your associated option. > + > + > 2000-04-20 Dave Love <[EMAIL PROTECTED]> > > * acspecific.m4 (AC_FUNC_MKTIME): Use AC_SUBST. > Index: acgeneral.m4 > === > RCS file: /cvs/autoconf/acgeneral.m4,v > retrieving revision 1.437 > diff -u -r1.437 acgeneral.m4 > --- acgeneral.m4 2000/04/13 08:25:12 1.437 > +++ acgeneral.m4 2000/04/26 10:41:21 > @@ -77,6 +77,8 @@ > # initialization code, option handling loop. > # - HELP_BEGIN > # Handling `configure --help'. > +# - HELP_CANON > +# Help msg for AC_CANONICAL_* > # - HELP_ENABLE > # Help msg from AC_ARG_ENABLE. > # - HELP_WITH > @@ -119,21 +121,25 @@ > define([_AC_DIVERT(NOTICE)], 1) > define([_AC_DIVERT(DEFAULTS)
Re: Definition of cross-compiling
On Fri, 28 Apr 2000, Peter Eisentraut wrote: > Okay, so I don't claim to know a thing about cross-compilation, but the > current confusion around these parts doesn't help either. So let's pose > this question: How do you *define* a cross-compilation situation, at least > for the purposes of the Autoconf environment? Among the suggestions were: Approach #1 may not be perfect, but it is a lot better than approach #2. Adding -cross or -nocross also seems like a hack if you ask me. Perhaps this is a stupid idea, but what about some kind of config.compare script that takes two arguments (the $host and the $build) and figures out if the two are "really the same" or if a cross compile is in order. There are always going to be all kinds of wacky combinations where if test "$host" != "$build" is just not going to cut it. Why don't we put these info a config.compare script that can be improved over time? Mo Dejong Red Hat Inc. > 1) build != host -- That won't work because firstly config.sub isn't quite > that smart to guarantee lexical equalness in all cases, the problem often > being the vendor part being kinda random. Secondly it will unnecessarily > restrict such cases as an i486 -> i586 build (or equivalent for sparc, > alpha, etc.) > > 2) Test program fails to run. That will not always catch things such as a > FreeBSD -> Linux build. But running a test program might fail because the > run-time environment isn't set up right, for example problems with the > dynamic linker. Or consider building in /tmp which might be mounted > noexec. What you really need to test is if the program would run at the > installation destination, but you can't really do that. > > So the --cross option being thrown around seems to indicate that you can't > really define it either way. (However, adding an option to turn on a > feature that isn't really defined strikes me as a little odd as well.) So > what's the deal? > > -- > Peter Eisentraut Sernanders väg 10:115 > [EMAIL PROTECTED] 75262 Uppsala > http://yi.org/peter-e/Sweden
Re: Autoconf fails to install without help2man
On 28 Apr 2000, Akim Demaille wrote: > I don't think your patch is right: you are hiding a problem. I think > `missing' should not exit 0 when it doesn't know what to do, but Ok, I will debate this. The script does print "WARNING:" not "ERROR : I dont know what to do". I would think that a warning should return 0 in all cases. > I suppose this is debatable. > > IMHO the right patch is to teach `help2man' to `missing'. It does > need to know a lot about it, the most important being --output. Then > missing shall just `touch' the output file. Are you saying that this "missing" script is actually part of the automake dist? So I would need to find it and submit patches to that project? Mo DeJong Red Hat Inc. > If you want to give it a try, you probably should do that with the > `missing' which is in CVS Automake. Autoconf will import it then. > > Akim
Re: help2man
Why not just include it in the CVS? It is really small. Anything that will make autoconf 2.14 easier to install is a good thing. help2man-1.020.tar.gz 32 k Mo Dejong Red Hat Inc. On Mon, 1 May 2000, Pavel Roskin wrote: > Hello! > > Shouldn't Autoconf sources mention somewhere what is the right version of > help2man and where to get it? Maybe we need a file HACKING? > > Regards, > Pavel Roskin > >
Re: Defining headers
I think you have run into a bug in autoheader. The problem seemes to be that a call to: AC_DEFINE(UNIX_FILE_SYSTEM) will not actually add the #define to config.h.in. I worked around this issue by always using 3 arguments to AC_DEFINE. AC_DEFINE(UNIX_FILE_SYSTEM,,[quick hack to use UNIX file system, fixme]) That worked, but I never got around to patching autoheader to fix the real problem. Mo Dejong Red Hat Inc. On Fri, 5 May 2000, R Leigh wrote: > Dear all, > I apologise in advance if this message is sent to the wrong forum. > > I have been using the autoconf/make programs on Debian GNU/Linux for some > months now and have found them to be very good. However, I have the > following question: > > If I define more than one header with AC_CONFIG_HEADER, (e.g. config.h and > src/defs.h (I have also created a suitable src/defs.h.in)) then if I > define a definition with AC_DEFINE (I used AC_DEFINE_UNQUOTED) the > substitution works when I run ./configure but when I run autoheader I get > errors because I have not included the definition in acconfig.h. However, > I must add it to acconfig.h as otherwise I cannot run `make distclean' > (autoheader fails again). If I do add it, then it is included in both > config.h and src/defs.h, and I get redefinition errors when compiling. > > Is there a way around this? I only want the definition to be substituted > in src/defs.h. > > If there is no way to do this then could I suggest this improvement to > autoheader: When autoheader parses configure.in, if there is a definition > that it does not find in acconfig.h, could it also parse additional > foo.h.in's specified by including foo.h with AC_CONFIG_HEADER. > > Many thanks for your help, > Roger Leigh > > -- > Roger Leigh > ** Registration Number: 151826, http://counter.li.org ** > >
autoconf is going nuts, it takes 100% of my CPU
Has anyone ever run into a problem like this before? I ran autoconf and it started sucking up all my CPU time. Here is the configure.in that causes the problem. mo(~)% autoconf /usr/bin/m4: memory exhausted AC_INIT(foo) AC_DEFUN(FOO, [ foo_cmd="$FOO $FOO_FLAGS arg" echo $foo_cmd ]) FOO Any ideas? Mo Dejong Red Hat Inc.
confusing warning from autoconf
Perhaps I am just doing something stupid here, but I just can not figure out why autoconf is printing a warning for this configure.in file. % cat configure.in AC_INIT(foo) AC_DEFUN(FOO, [ foo_cmd="$JAVAC $JAVAC_FLAGS Test.java" echo $foo_cmd ]) FOO % autoconf autoconf: undefined macros: configure.in:5:foo_cmd="$JAVAC $JAVAC_FLAGS Test.java" Any ideas? Mo Dejong Red Hat Inc.
Error running config.status.
Here is an interesting little bug that I just ran into. I am running
autoconf out of the CVS.
~/project/tcljava/configure --with-kaffe=/home/mo/project/install/kaffe
--enable-jacl --with-jikes=/home/mo/project/build/jikes/src/jikes
...
creating ./config.status
./config.status: --enable-jacl: command not found
% head config.status
#! /bin/sh
# Generated automatically by configure.
# Run this file to recreate the current configuration.
# Compiler output produced by configure, useful for debugging
# configure, is in ./config.log if it exists.
configure=/home/mo/project/tcljava/configure
configure_args=--with-kaffe=/home/mo/project/install/kaffe --enable-jacl
--with-jikes=/home/mo/project/build/jikes/src/jikes
debug=false
me=`echo "$0" | sed -e 's,.*/,,'`
The problem seems to be that configure_args is getting written without
a "", and that is causing it to fail.
% ./config.status
./config.status: --enable-jacl: command not found
If I add the double quotes by hand, then config.status will work again.
% diff -u copy_config.status config.status
--- copy_config.status Mon May 22 13:08:26 2000
+++ config.status Mon May 22 13:09:23 2000
@@ -5,7 +5,7 @@
# configure, is in ./config.log if it exists.
configure=/home/mo/project/tcljava/configure
-configure_args=--with-kaffe=/home/mo/project/install/kaffe --enable-jacl
--with-jikes=/home/mo/project/build/jikes/src/jikes
+configure_args="--with-kaffe=/home/mo/project/install/kaffe
--enable-jacl --with-jikes=/home/mo/project/build/jikes/src/jikes"
debug=false
me=`echo "$0" | sed -e 's,.*/,,'`
SHELL=${CONFIG_SHELL-/bin/sh}
Mo Dejong
Red Hat Inc.
Re: TODO list for release?
How much interest would there be in adding Java to the autoconf supported languages? I would be willing to convert some of the existing Java detect and compile macros over to the autoconf framework if folks were cool with the idea of adding Java support. I already have some nice macros that can find JDK info for many platforms as well as Kaffe. This would also be an idea place to add support for gcj as a standard Java target. Mo Dejong Red Hat Inc.
Re: Java for Autoconf (was: TODO list for release?)
On Mon, 29 May 2000, Steven G. Johnson wrote: > The Autoconf macro archive (http://research.cys.de/autoconf-archive/) has > a number of Java macros already. I haven't used them myself and can't > vouch for their quality, nor do I know how they compare to yours, but it > seems like it would be a good thing for you to take a look at them and > coordinate with their authors. Ideally, you could merge the work, or at > least benefit from the experiences that they've had, give everyone credit, > and produce a single definitive set of high-quality Java macros. (Much > better than to have a lot of different versions running around for no good > reason.) I have already looked at them. There were a number of very strange things in that set of macros. In the end, it was just easier to write up my own macros to invoke the compiler instead of playing around with the ones on the macro archive. I am not trying to say anything bad about Mr. Bortzmeyer or his macros, I just don't think they are the right way to go. > I don't know how the autoconf maintainers feel about it, but I don't think > they should attempt to include this sort of major thing for the next > release. Rather, you could post the results to the macro archive for a > while, get feedback, and then after it had settled down and everyone was > happy you could be devoured by the all-powerful Autoconf. The thing I have noticed about open source projects is that the only way to get things done is to decide on a goal and then do 99% of the work needed to reach that goal. Other folks are happy to make comments on the work you did or polish up the 1% you did wrong, but nobody is going to do the work for you. My goal is to get Java support into autoconf so that I do not need to maintain my own set of compiler macros. If folks can agree that Java support in autoconf is a good thing, then I will do most of the work needed to make that happen. I am not going to waste lots of time hacking autoconf if people are not interested in adding Java support. It is also a waste of my time to put these macros on the macro archive. The macro archive is not the place for language support in autoconf! If you want to get folks using and improving Java macros, you need to make them part of the "standard" install. Mo Dejong Red Hat Inc.
Problem with removal of AC_CHECK_TOOL_PREFIX and libtool
I just ran into a strange error when I tried to use the most
recent version of autoconf to configure SDL. Here is the
error:
% autoconf
autoconf: undefined macros:
***BUG in Autoconf--please report*** AC_CHECK_TOOL_PREFIX
It seems that AC_CHECK_TOOL_PREFIX is getting called somewhere.
mo(~/project/SDL)% grep AC_CHECK_TOOL_PREFIX *
acinclude.m4:[AC_REQUIRE([AC_CHECK_TOOL_PREFIX])dnl
This acinclude.m4 file seems to have been generated
by libtool. I found the following macro inside it.
# AC_PATH_TOOL_GREP_OUTPUT - Try AC_PATH_PROG_GREP_OUTPUT with target
# prefix when cross-compiling
dnl AC_PATH_TOOL_GREP_OUTPUT(VARIABLE, PROG-TO-CHECK-FOR,
GREP-EXPRESSION[, VALUE-IF-NOT-FOUND [, PATH]])
AC_DEFUN(AC_PATH_TOOL_GREP_OUTPUT,
[AC_REQUIRE([AC_CHECK_TOOL_PREFIX])dnl
AC_PATH_PROG_GREP_OUTPUT($1, ${ac_tool_prefix}$2, $3,
ifelse([$4], , [$2], ), $5)
Note how it calls AC_REQUIRE on the AC_CHECK_TOOL_PREFIX macro
which is now in bit heaven. I am at a bit of a loss when
it comes to the "right" way to fix this problem. Is this
something that needs to be fixed in libtool, or should
autoconf leave and empty macro def for AC_CHECK_TOOL_PREFIX
in case older versions of tools use it?
thanks
Mo Dejong
Red Hat Inc.
Re: TODO list for release?
On 30 May 2000, Alexandre Oliva wrote: > On May 29, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > > > How much interest would there be in adding Java to the > > autoconf supported languages? > > It'd certainly be appreciated. But we have to be careful, since there > are two (three?) kinds of Java compilers: those that translate Java > source to bytecode, and those (that?) that translate(s?) Java source > (or bytecode) to object code. > > We could certainly ``steal'' automake's AM_PROG_GCJ (renamed to > AC_PROG_GCJ) for the second (and third) uses, but we'd still need > something like AC_PROG_JAVAC, which seems to be what you already have: > it should look for at least javac, jikes, `$JAVA at.dms.kjc.Main' > (Kopi) and `gcj -C', but determining the preference order is not easy. > I, for one, have found packages that will build with some, but not > all, of these compilers. > > I'd certainly welcome this effort, but I don't think this is something > for autoconf 2.50. I suggest that you start by contributing your > macros to the autoconf macro archive. Then, after the release, we > could merge them into autoconf. How does this sound for you? I am not really interested in doing that. If Java is not going to be one of the "standard languages" in the next version of autoconf, then I would be better off just using my own macros. The whole reason I want to see Java support in autoconf is to avoid the the following scenario: Q: Can I use Java in autoconf? A: Sure just go to this site and download a bunch of unsupported macros that may or may not work. Then figure out how to install them. Finally, cross your fingers, hope, and press the enter key. Q: I tried that and I can't figure out how to get things working. What should I do? A: Send that Mo guy email until he fixes the problem. Mo Dejong Red Hat Inc.
Re: Autoconf suggestion
On Wed, 31 May 2000, Keith Bostic wrote: > I'd like to make a small suggestion for autoconf -- it would be helpful > in debugging configuration problems if the output that is displayed on > the screen during configuration: > > checking for gcc... cc > checking whether the C compiler (cc -O2 -g ) works... yes > checking whether the C compiler (cc -O2 -g ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether cc accepts -g... yes > checking for c++... g++ > checking whether the C++ compiler (g++ -O2 -g ) works... yes > checking whether byte ordering is bigendian... no > > were also copied into the config.log output. The problem is that users > send us the config.log file when configuration fails, but NOT the screen > output, and so we have to translate from the following: > > configure:1027: checking for gcc > configure:1140: checking whether the C compiler (gcc -O ) works > configure:1156: gcc -o conftest -O -D_REENTRANT conftest.c 1>&5 > configure:1182: checking whether the C compiler (gcc -O ) is a cross-compiler > configure:1187: checking whether we are using GNU C > configure:1196: gcc -E conftest.c > configure:1215: checking whether gcc accepts -g > configure:1754: checking whether byte ordering is bigendian > configure:1772: gcc -c -O -D_REENTRANT conftest.c 1>&5 > > without knowing what the answer to the question was. > > I would also encourage putting the source for all test programs into the > config.log file too, not just the failed ones. I don't know about other > folks, but we use config.log for the sole purpose of debugging problems, > and so the more information we can get in that file, the better off we are. > > Thanks, as always, for a great tool. > > Regards, > --keith Keith makes a good point. I ended up creating my own AC_MSG_LOG macro that would write a message to the console and the log file because of this exact problem. I don't see any reason the config.log should not contain all the output instead of just "checking yes|no". Mo Dejong Red Hat Inc.
Problem with AC_OUTPUT macro
Hi all.
I have run into a problem with a configure.in that worked
just fine with autoconf 2.13 but not 2.14.
% cat configure.in
AC_INIT(foo.cpp)
AC_LANG_CPLUSPLUS
AC_PROG_CXX
AC_PROG_CC
PROCESS_FILES="Makefile src/Makefile"
AC_OUTPUT([$PROCESS_FILES])
% /usr/bin/autoconf --version
Autoconf version 2.13
% /usr/bin/autoconf
% ./configure
creating cache ./config.cache
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating src/Makefile
And now the CVS version.
% autoconf --version
autoconf (GNU autoconf) 2.14a
% autoconf
% ./configure
checking for g++... g++
checking whether the C++ compiler works... yes
checking whether we are using GNU C++... yes
checking whether g++ accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for EMX OS/2 environment... no
checking for executable suffix...
checking for object suffix... o
checking for gcc... gcc
checking whether the C compiler works... yes
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
creating ./config.status
autoconf 2.14 creates the ./config.status file
but when run, config.status does create
the Makefiles.
The problem seems to be related to the
AC_OUTPUT macro. Here is what is written
into the config.status file.
# Files that config.status was made for.
config_files="\
$PROCESS_FILES"
That PROCESS_FILES variable should have been
substitued in the ./configure script.
Here is what gets put into the ./configure script
when autoconf 2.13 is run.
PROCESS_FILES="Makefile src/Makefile"
...
trap 'rm -fr `echo "$PROCESS_FILES" | sed "s/:[^ ]*//g"` conftest*; exit
1' 1 2 15
...
CONFIG_FILES=\${CONFIG_FILES-"$PROCESS_FILES"}
...
Here is what gets put into the ./configure script
when autoconf 2.14 is run.
PROCESS_FILES="Makefile src/Makefile"
...
# Files that config.status was made for.
config_files="\
$PROCESS_FILES"
...
# Handling of arguments.
'$PROCESS_FILES' ) CONFIG_FILES="$CONFIG_FILES $PROCESS_FILES" ;;
How can this be fixed?
Mo DeJong
Red Hat Inc
Getting a "cannot run" message from ./configure
I just tried to run a configure script
generated by the CVS version of autoconf.
% ~/project/tkgs/configure
configure: error: cannot run
This was caused by a check for config.sub
the file did not exist in my src tree.
This is a problem, but the test is also
broken because the AC_CONFIG_AUX_DIR_DEFAULT
seems to be getting expanded after the
AC_CANONICAL_BUILD macro. The result
is the following in the generated configure.
(line 699)
# Make sure we can run config.sub.
$ac_config_sub sun4 >/dev/null 2>&1 ||
{ echo "configure: error: cannot run config.sub = $ac_config_sub" >&2;
exit 1; }
(line 816)
if test -z "$ac_aux_dir"; then
{ echo "configure: error: cannot find install-sh or install.sh in
$srcdir $srcdir/.. $srcdir/../.." >&2; exit 1; }
fi
ac_config_guess="$SHELL $ac_aux_dir/config.guess"
ac_config_sub="$SHELL $ac_aux_dir/config.sub"
ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus
configure.
The ac_config_sub is getting set after it is getting used
(inside the AC_CANONICAL_BUILD macro).
Here is what the defs in acgeneral look like:
# AC_CANONICAL_BUILD
# --
AC_DEFUN_ONCE([AC_CANONICAL_BUILD],
[AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
AC_DIVERT([HELP_CANON],
[[
Hosts type:
--build=BUILD configure for building on BUILD [guessed]]])dnl
# Make sure we can run config.sub.
$ac_config_sub sun4 >/dev/null 2>&1 ||
AC_MSG_ERROR([cannot run config.sub = $ac_config_sub])
AC_CACHE_CHECK([build system type], [ac_cv_build],
[ac_cv_build_alias=$build_alias
test -z "$ac_cv_build_alias" &&
ac_cv_build_alias=`$ac_config_guess`
test -z "$ac_cv_build_alias" &&
AC_MSG_ERROR([cannot guess build type; you must specify one])
ac_cv_build=`$ac_config_sub $ac_cv_build_alias` || exit 1
])
_AC_CANONICAL_SPLIT(build)
])# AC_CANONICAL_BUILD
# AC_CONFIG_AUX_DIR_DEFAULT
# -
# The default is `$srcdir' or `$srcdir/..' or `$srcdir/../..'.
# There's no need to call this macro explicitly; just AC_REQUIRE it.
AC_DEFUN([AC_CONFIG_AUX_DIR_DEFAULT],
[AC_CONFIG_AUX_DIRS($srcdir $srcdir/.. $srcdir/../..)])
# AC_CONFIG_AUX_DIRS(DIR ...)
# ---
# Internal subroutine.
# Search for the configuration auxiliary files in directory list $1.
# We look only for install-sh, so users of AC_PROG_INSTALL
# do not automatically need to distribute the other auxiliary files.
AC_DEFUN([AC_CONFIG_AUX_DIRS],
[ac_aux_dir=
for ac_dir in $1; do
if test -f $ac_dir/install-sh; then
ac_aux_dir=$ac_dir
ac_install_sh="$ac_aux_dir/install-sh -c"
break
elif test -f $ac_dir/install.sh; then
ac_aux_dir=$ac_dir
ac_install_sh="$ac_aux_dir/install.sh -c"
break
elif test -f $ac_dir/shtool; then
ac_aux_dir=$ac_dir
ac_install_sh="$ac_aux_dir/shtool install -c"
break
fi
done
if test -z "$ac_aux_dir"; then
AC_MSG_ERROR([cannot find install-sh or install.sh in $1])
fi
ac_config_guess="$SHELL $ac_aux_dir/config.guess"
ac_config_sub="$SHELL $ac_aux_dir/config.sub"
ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus
configure.
AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
])# AC_CONFIG_AUX_DIRS
I am stumped. Is something wrong with the
AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT]) such
that is no longer includes the text from
AC_CONFIG_AUX_DIR_DEFAULT?
Mo DeJong
Red Hat Inc
Re: Getting a "cannot run" message from ./configure
On 6 Jun 2000, Akim Demaille wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > Mo> I am stumped. Is something wrong with the > Mo> AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT]) such that is no longer > Mo> includes the text from AC_CONFIG_AUX_DIR_DEFAULT? > > Could you set up a small configure.in which demonstrates the problem? I am now convinced that this problem is caused by something that libtool is doing. I have found that the most simple way to get this error is to grab the CVS version of libtool and try to build it using the CVS version of autoconf. I really have no idea what libtool could be doing that would cause it to generate these macros in the wrong order. It seems to something unholy indeed. The only other info I have is the ugly hack I used to get around the problem. This is NOT a patch, it is more of an example of how not to solve the problem :) Mo DeJong Red Hat Inc Index: acgeneral.m4 === RCS file: /cvs/autoconf/acgeneral.m4,v retrieving revision 1.482 diff -u -r1.482 acgeneral.m4 --- acgeneral.m42000/06/05 16:05:49 1.482 +++ acgeneral.m42000/06/06 07:58:06 @@ -1811,7 +1816,19 @@ ac_config_guess="$SHELL $ac_aux_dir/config.guess" ac_config_sub="$SHELL $ac_aux_dir/config.sub" ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus configure. -AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl +# Make sure we can run config.sub. +$ac_config_sub sun4 >/dev/null 2>&1 || + AC_MSG_ERROR([cannot run config.sub = $ac_config_sub]) + +AC_CACHE_CHECK([build system type], [ac_cv_build], +[ac_cv_build_alias=$build_alias +test -z "$ac_cv_build_alias" && + ac_cv_build_alias=`$ac_config_guess` +test -z "$ac_cv_build_alias" && + AC_MSG_ERROR([cannot guess build type; you must specify one]) +ac_cv_build=`$ac_config_sub $ac_cv_build_alias` || exit 1 +]) +dnl AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl ])# AC_CONFIG_AUX_DIRS @@ -1853,18 +1870,6 @@ [[ Hosts type: --build=BUILD configure for building on BUILD [guessed]]])dnl -# Make sure we can run config.sub. -$ac_config_sub sun4 >/dev/null 2>&1 || - AC_MSG_ERROR([cannot run $ac_config_sub]) - -AC_CACHE_CHECK([build system type], [ac_cv_build], -[ac_cv_build_alias=$build_alias -test -z "$ac_cv_build_alias" && - ac_cv_build_alias=`$ac_config_guess` -test -z "$ac_cv_build_alias" && - AC_MSG_ERROR([cannot guess build type; you must specify one]) -ac_cv_build=`$ac_config_sub $ac_cv_build_alias` || exit 1 -]) _AC_CANONICAL_SPLIT(build) ])# AC_CANONICAL_BUILD
Are AC_EXEEXT and AC_OBJEXT called by default?
I was looking back at the ChangeLog when I noticed this: 2000-05-23 Akim Demaille <[EMAIL PROTECTED]> Simplify the interface: users shouldn't need to explicitly check for special environments. * acspecific.m4 (AC_EXEEXT, AC_OBJEXT): AU defined to nothing. Replace them by... (_AC_EXEEXT, _AC_OBJEXT): this. Does this mean that I should not need to call AC_EXEEXT and AC_OBJEXT in my configure.in? Calling these two macros by default seems like a good idea. Only problem is, when I remove them from my configure.in my Makefile.in seems to revert back to a non-portable state. (this file is generated by automake). @@ -218,8 +216,8 @@ maintainer-clean-compile: -jikes$(EXEEXT): $(jikes_OBJECTS) $(jikes_DEPENDENCIES) - @rm -f jikes$(EXEEXT) +jikes: $(jikes_OBJECTS) $(jikes_DEPENDENCIES) + @rm -f jikes $(CXXLINK) $(jikes_LDFLAGS) $(jikes_OBJECTS) $(jikes_LDADD) $(LIBS) .cpp.o: $(CXXCOMPILE) -c $< Is this a problem that needs to be fixed in automake or am I just missing something? Mo Dejong Red Hat Inc.
Is anyone else seeing this strange autoconf error?
I have seen this error a number of times, but it does not seem to be reproducible. Has anyone run into anything like this using the CVS version of autoconf? It seems to happen during this Macro eval: AC_CHECK_HEADERS(ctype.h time.h float.h) ./configure ... checking for time.h... yes checking for float.h... /home/mo/project/jikes/configure: Can't reopen pipe to command substitution (fd 4): No child processes yes checking for iconv.h... no checking for windows.h... yes It my box hosed or what? Mo Dejong Red Hat Inc.
Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust
On 14 Jun 2000, Akim Demaille wrote: > >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: > > Alexandre> Because some compilers just print a warning message and > Alexandre> proceed. GCC on HP/UX without GNU as is a good example. ... > So, I think we should base our conclusion upon conftest.o, not > stderr+stdout. Perhaps this is a silly idea, but why don't you just run the compiler without the -g flag to make sure that it created a conftest.o file, and then run with the -g flag but check that the produced conftest.o is larger than the first one. If -g adds debug info to conftest.o then it is going to get bigger. If -g is not known to the compiler, it should produce a .o file that is exactly the same size. That way you could avoid all the stdio+stderr junk. Mo DeJong Red Hat Inc.
Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust
On 16 Jun 2000, Akim Demaille wrote:
> >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> Alexandre> On Jun 14, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> >> Perhaps this is a silly idea, but why don't you just run the
> >> compiler without the -g flag to make sure that it created a
> >> conftest.o file, and then run with the -g flag but check that the
> >> produced conftest.o is larger than the first one.
>
> Alexandre> I like this approach!
>
> Fine with me too.
>
> Mo, yet another patch? :)
Well, something like the following patch would work.
This is kind of wacky because the only way I could figure
out how to get the length of a binary file was to use
od and then measure the string length of that. If someone
else has a better idea I am all for it. Also, _AC_PROG_CXX_G
would need to do the same thing. Of course, there does not
seem to be any need to have two macros. How about merging
them into a more generic AC_PROG_COMPILER_G macro
that could test any compiler for the -g flag?
Mo DeJong
Red Hat Inc
Index: aclang.m4
===
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.30
diff -u -r1.30 aclang.m4
--- aclang.m4 2000/06/07 07:16:16 1.30
+++ aclang.m4 2000/06/16 15:44:37
@@ -604,10 +609,32 @@
# _AC_PROG_CC_G
#
+# There is no dependable way to check to see if a compiler
+# supports a given flag. In the case of the -g flag, we can
+# test to see if -g adds debug info the the object file by
+# seeing if the produced object file get bigger when the
+# -g option is passed in to the compiler.
define([_AC_PROG_CC_G],
[AC_CACHE_CHECK(whether ${CC-cc} accepts -g, ac_cv_prog_cc_g,
[echo 'void f(){}' >conftest.c
-if test -z "`${CC-cc} -g -c conftest.c 2>&1`"; then
+# First, make sure an object file is generated
+AC_TRY_COMMAND(${CC-cc} -c conftest.c)
+if test ! -s conftest.${ac_objext} ; then
+AC_MSG_ERROR([Compiler did not produce an object file with -c flag])
+fi
+mv conftest.${ac_objext} conftest_smaller.${ac_objext}
+# Run the compiler with the -g flag
+AC_TRY_COMMAND(${CC-cc} -c -g conftest.c)
+mv conftest.${ac_objext} conftest_bigger.${ac_objext}
+# Now figure out how big each file is
+ac_cv_prog_cc_g_smaller=`od conftest_smaller.o`
+ac_cv_prog_cc_g_smaller=${#ac_cv_prog_cc_g_smaller}
+ac_cv_prog_cc_g_bigger=`od conftest_bigger.o`
+ac_cv_prog_cc_g_bigger=${#ac_cv_prog_cc_g_bigger}
+dnl echo "ac_cv_prog_cc_g_smaller = $ac_cv_prog_cc_g_smaller" >&AC_FD_LOG
+dnl echo "ac_cv_prog_cc_g_bigger = $ac_cv_prog_cc_g_bigger" >&AC_FD_LOG
+# If the object file generated with -g is bigger, then -g works
+if test $ac_cv_prog_cc_g_bigger -gt $ac_cv_prog_cc_g_smaller ; then
ac_cv_prog_cc_g=yes
else
ac_cv_prog_cc_g=no
Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust
On Fri, 16 Jun 2000, Thomas E. Dickey wrote: > On Fri, 16 Jun 2000, Mo DeJong wrote: > > Well, something like the following patch would work. > ...something like (there are two places the look like problems): > > > +ac_cv_prog_cc_g_smaller=`od conftest_smaller.o` > > od will suppress rows that contain only 0's, making the size look > different. We don't care about the exact size, only that one object file is bigger than the other. > > +if test $ac_cv_prog_cc_g_bigger -gt $ac_cv_prog_cc_g_smaller ; then > why do you think the output of `od` will be a single number? > (Perhaps output of 'ls', but that gets into the problem of getting a > format of ls). Because earlier in the test ac_cv_prog_cc_g_bigger is set to the length of the output of od. > Better to simply run a test program that uses only stdio.h (checking if > opening the object file in binary mode works ;-) That might not be a bad idea. I don't like to depend on od just to get the size of a file. Am I just missing something? Is there an easy way to figure out the size of a binary file in bytes? `ls` or `ls -S` is not going to cut it. Mo DeJong Red Hat Inc
Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust
On 16 Jun 2000, Akim Demaille wrote:
> >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> That might not be a bad idea. I don't like to depend on od just to
> Mo> get the size of a file. Am I just missing something? Is there an
> Mo> easy way to figure out the size of a binary file in bytes?
>
> Autoconf 2.13 says:
>
> ac_lines=`grep -c . conftest.vals`
> # grep -c gives empty output for an empty file on some AIX systems.
> if test -z "$ac_lines" || test "$ac_lines" -eq 0; then break; fi
>
> so I guess this means you can rely on grep -c. But really, don't fear
> using wc -c, just write your test in such a way that it is pessimistic
> is wc fails.
>
> Akim
I like that wc -c a lot better, we can just do this. Of course
this depends on the output format of wc, is it going to
be the same everywhere? We just need the first word
to be the size.
for ac_cv_prog_cc_g_smaller in `wc -c conftest_smaller.o` ; do
break
done
Mo DeJong
Red Hat Inc
Index: aclang.m4
===
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.34
diff -u -r1.34 aclang.m4
--- aclang.m4 2000/06/09 11:14:05 1.34
+++ aclang.m4 2000/06/16 18:18:04
@@ -604,10 +609,34 @@
# _AC_PROG_CC_G
#
+# There is no dependable way to check to see if a compiler
+# supports a given flag. In the case of the -g flag, we can
+# test to see if -g adds debug info the the object file by
+# seeing if the produced object file get bigger when the
+# -g option is passed in to the compiler.
define([_AC_PROG_CC_G],
[AC_CACHE_CHECK(whether ${CC-cc} accepts -g, ac_cv_prog_cc_g,
[echo 'void f(){}' >conftest.c
-if test -z "`${CC-cc} -g -c conftest.c 2>&1`"; then
+# First, make sure an object file is generated
+AC_TRY_COMMAND(${CC-cc} -c conftest.c)
+if test ! -s conftest.${ac_objext} ; then
+AC_MSG_ERROR([Compiler did not produce an object file with -c flag])
+fi
+mv conftest.${ac_objext} conftest_smaller.${ac_objext}
+# Run the compiler with the -g flag
+AC_TRY_COMMAND(${CC-cc} -c -g conftest.c)
+mv conftest.${ac_objext} conftest_bigger.${ac_objext}
+# Now figure out how big each file is
+for ac_cv_prog_cc_g_smaller in `wc -c conftest_smaller.o` ; do
+ break
+done
+for ac_cv_prog_cc_g_bigger in `wc -c conftest_bigger.o` ; do
+ break
+done
+dnl echo "ac_cv_prog_cc_g_smaller = $ac_cv_prog_cc_g_smaller" >&AC_FD_LOG
+dnl echo "ac_cv_prog_cc_g_bigger = $ac_cv_prog_cc_g_bigger" >&AC_FD_LOG
+# If the object file generated with -g is bigger, then -g works
+if test "${ac_cv_prog_cc_g_bigger}0" -gt "${ac_cv_prog_cc_g_smaller}0" ;
then
ac_cv_prog_cc_g=yes
else
ac_cv_prog_cc_g=no
Re: --host => cross breaks GCC builds
On 16 Jun 2000, Alexandre Oliva wrote:
> GCC and Sourceware src (== Cygnus)'s top-level configure always passes
> --build, --host and --target down to sub-directories. Therefore, we
> must not assume that, just because --host is given, we're cross
> compiling.
>
> Comparing build with host and deciding for cross compilation if they
> differ might be reasonable, but it still breaks backward
> compatibility, and some Cygnus folks have complained about having to
> modify lots of scripts to accomodate this change.
What this basically comes down to is, should --host=$TRIPLE
automatically assume a cross compile? The current version
of autoconf breaks backward compatibility with older
versions in the case where people are using the
--host argument to indicate the build system. It is
debatable if that is right or wrong, but it is the
way autoconf used to work. The downside to switching
back to the old approach is that it makes cross
compiling harder as folks would need to
give both --build and --host to do a cross.
There is a case where the new behavior is clearly wrong.
That is when --build and --host are both given and they
are exactly the same. I have appended a patch to
fix that problem.
Mo DeJong
Red Hat Inc
Index: acgeneral.m4
===
RCS file: /cvs/autoconf/acgeneral.m4,v
retrieving revision 1.488
diff -u -r1.488 acgeneral.m4
--- acgeneral.m42000/06/16 17:40:44 1.488
+++ acgeneral.m42000/06/16 18:48:13
@@ -829,7 +829,6 @@
# Initializations.
#
ac_default_prefix=/usr/local
-cross_compiling=no
subdirs=
MFLAGS= MAKEFLAGS=
AC_SUBST(SHELL, ${CONFIG_SHELL-/bin/sh})dnl
@@ -1054,10 +1053,8 @@
ac_init_help=short ;;
-host | --host | --hos | --ho)
-cross_compiling=yes
ac_prev=host_alias ;;
-host=* | --host=* | --hos=* | --ho=*)
-cross_compiling=yes
host_alias=$ac_optarg ;;
-includedir | --includedir | --includedi | --included | --include \
@@ -1289,9 +1286,18 @@
host=$host_alias
target=$target_alias
-ac_tool_prefix=
-test -n "$host_alias" && ac_tool_prefix=$host_alias-
-
+# There might be people who have scripts that pass in --build and --host.
+# In this case, we do not want to cross compile if the --build and --host
+# arguments are exactly the same (it is just a native build). In the
+# case where only --host is given we want to do a Canadian cross.
+
+if test "x$host_alias" = "x" || test "$host_alias" = "$build_alias" ; then
+ cross_compiling=no
+ ac_tool_prefix=
+else
+ cross_compiling=yes
+ ac_tool_prefix=$host_alias-
+fi
AC_DIVERT_POP()dnl
])# _AC_INIT_PARSE_ARGS
Index: aclang.m4
===
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.34
diff -u -r1.34 aclang.m4
--- aclang.m4 2000/06/09 11:14:05 1.34
+++ aclang.m4 2000/06/16 18:48:14
@@ -469,9 +469,14 @@
# AC_LANG_COMPILER_WORKS
# --
define([_AC_LANG_COMPILER_WORKS],
-[AC_MSG_CHECKING([whether the _AC_LANG compiler works])
+[
+AC_MSG_CHECKING([whether we are cross compiling])
+AC_MSG_RESULT($cross_compiling)
+
+AC_MSG_CHECKING([whether the _AC_LANG compiler works])
AC_LINK_IFELSE([AC_LANG_PROGRAM()],
-[# If not cross compiling, check that we can run a simple program.
+[
+# If not cross compiling, check that we can run a simple program.
if test $cross_compiling != yes; then
if AC_TRY_COMMAND(./conftest); then :; else
AC_MSG_RESULT(no)
problem with AC_CHECK_TOOLS rewrite
I just updated and got this change to the AC_CHECK_TOOLS macro: 2000-06-09 Akim Demaille <[EMAIL PROTECTED]> * acgeneral.m4 (AC_CHECK_TOOLS): Rewrite. While the rewrite is not really "wrong", it is also not as "right" as the old macro. Here is what is printed when I run the new macro. % ./configure checking for g++... g++ checking for c++... (cached) g++ checking for gpp... (cached) g++ checking for aCC... (cached) g++ checking for CC... (cached) g++ checking for cxx... (cached) g++ checking for cc++... (cached) g++ checking for cl... (cached) g++ checking for KCC... (cached) g++ checking for RCC... (cached) g++ checking for xlC_r... (cached) g++ checking for xlC... (cached) g++ checking for g++... (cached) g++ checking whether we are cross compiling... no checking whether the C++ compiler works... yes That is really ugly! Mo Dejong Red Hat Inc.
Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust
On Sat, 17 Jun 2000, Peter Eisentraut wrote: > Mo DeJong writes: > > > How about merging them into a more generic AC_PROG_COMPILER_G macro > > that could test any compiler for the -g flag? > > That would be nice because then we can undefine it so that AC_PROG_CC et > al don't run it. (or any other semi-stable interface to avoid automatic -g > in CFLAGS ...) That does not seem like a very good idea. The default should be -g -02 so that a binary will run with some optimizations and still be debugable in case of a crash. If folks want to do a release, then they can take out debug info an use more optimizations in the Makefile or just set CFLAGS before running configure. Mo DeJong Red Hat Inc
Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust
On 17 Jun 2000, Alexandre Oliva wrote:
> On Jun 16, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > I like that wc -c a lot better, we can just do this. Of course
> > this depends on the output format of wc, is it going to
> > be the same everywhere?
>
> I'm not even sure `wc -c' will be available everywhere :-(
> I still think using cmp is the best solution.
Ok, how about this patch? It uses cmp instead of wc.
I like this approach because we do not depend on
the output format of the wc program.
Mo DeJong
Red Hat Inc
Index: aclang.m4
===
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.34
diff -u -r1.34 aclang.m4
--- aclang.m4 2000/06/09 11:14:05 1.34
+++ aclang.m4 2000/06/18 03:54:54
@@ -604,13 +609,27 @@
# _AC_PROG_CC_G
#
+# There is no dependable way to check to see if a compiler
+# supports a given flag. In the case of the -g flag, we can
+# test to see if -g adds debug info the the object file by
+# seeing if the produced object file get bigger when the
+# -g option is passed in to the compiler.
define([_AC_PROG_CC_G],
[AC_CACHE_CHECK(whether ${CC-cc} accepts -g, ac_cv_prog_cc_g,
[echo 'void f(){}' >conftest.c
-if test -z "`${CC-cc} -g -c conftest.c 2>&1`"; then
- ac_cv_prog_cc_g=yes
-else
+# First, make sure an object file is generated
+AC_TRY_COMMAND(${CC-cc} -c conftest.c)
+if test ! -s conftest.${ac_objext} ; then
+AC_MSG_ERROR([Compiler did not produce an object file with -c flag])
+fi
+mv conftest.${ac_objext} conftest_smaller.${ac_objext}
+# Run the compiler with the -g flag
+AC_TRY_COMMAND(${CC-cc} -c -g conftest.c)
+# If the files are exactly the same, -g does not insert debug symbols
+if AC_TRY_COMMAND(cmp conftest_smaller.${ac_objext}
conftest.${ac_objext} >&AC_FD_LOG) ; then
ac_cv_prog_cc_g=no
+else
+ ac_cv_prog_cc_g=yes
fi
rm -f conftest*
])])# _AC_PROG_CC_G
Re: [gnu.utils.bug] AC_PROG_CC_G, et al, are not very robust
On 18 Jun 2000, Alexandre Oliva wrote: > On Jun 18, 2000, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > > > On Jun 18, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > >> Ok, how about this patch? It uses cmp instead of wc. > > > Nope, you must use `tail +16' > > +16c, I mean. Just like GCC's compare. > > But it occurs to me that `tail +16c' may not be supported, so we'd > have to somehow detect this and fallback to plain cmp, possibly > misdetecting `-g' as working. This is really messy. Why is there no way to find the length of a file in bash? That is all we really want to do. If the file gets bigger, then -g is supported. What about ls -S, is that portable? Some folks have suggested compiling and running a C program to figure out the length of the file, but that would not help if I wanted to do a cross compile. What if we used cmp, but wrote some null bytes over the first 16 bytes of each object file before we did the compare? Mo DeJong Red Hat Inc
What does this AC_PROVIDE do? (the "cannot run" bug)
I am trying to track down the "cannot run" but that causes libtool to fail to work with the current version of autoconf. In looking at AC_CONFIG_AUX_DIRS, I am left wondering what this call to AC_PROVIDE is for. AC_DEFUN([AC_CONFIG_AUX_DIRS], ... if test -z "$ac_aux_dir"; then AC_MSG_ERROR([cannot find install-sh or install.sh in $1]) fi ac_config_guess="$SHELL $ac_aux_dir/config.guess" ac_config_sub="$SHELL $ac_aux_dir/config.sub" ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus configure. AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl < RIGHT HERE ])# AC_CONFIG_AUX_DIRS I could be off in left field here, but should this AC_PROVIDE be here? Mo DeJong Red Hat Inc
News on "cannot run" error
Ok, I have at least found how to work around the "cannot run" error when using the most recent version of autoconf with libtool. If you add calls to AC_CANONICAL_HOST and AC_CANONICAL_BUILD before calling AC_PROG_LIBTOOL, that seems to work around the problem. I am still not clear on exactly why AC_PROG_LIBTOOL by itself will use ac_config_sub before it is actually defined. It has something to do with the order that AC_CONFIG_AUX_DIR_DEFAULT is getting defined in, but that is all I know at this point. dnl Set up host checks using config.sub and config.guess. AC_CANONICAL_HOST AC_CANONICAL_BUILD AC_PROG_LIBTOOL Mo DeJong Red Hat Inc
Re: build/host/target?
On Sat, 24 Jun 2000 [EMAIL PROTECTED] wrote: > Is the build/host/target stuff fully explained anywhere? > > standards.texi talks about using host/target, autoconf.texi talks just a > bit about these items. I remember the flurry of email that recently > happened on this matter, but I sure didn't get a clear understanding of > any resolution. The following appears in info/autoconf.info, If things are still murky after reading this, feel free to make suggestions on how it could be improved. This cross build stuff has suffered from poor documentation and confused semantics for some time, so it would be nice to get it all ironed out before the next release. `--build=BUILD-TYPE' the type of system on which the package is being configured and compiled (rarely needed). `--host=HOST-TYPE' the type of system on which the package will run. `--target=TARGET-TYPE' the type of system for which any compiler tools in the package will produce code (rarely needed). By default, the build system type is guessed (by `config.guess'), the host system is the build system, and the target is the host system. Using `--host=HOST-TYPE' enables cross-compilation. line, e.g., ./configure --host=m68k-coff > For example, years ago I added the ability to compile the NTP software > for vxworks (with a bunch of help from a vxworks person). At that time, > for whatever reason, I tested the various AC_CANONICAL_* macros and > decided I needed to use AC_CANONICAL_SYSTEM and compare $host with > $target in configure.in . > > Should I change to AC_CACNONICAL_HOST and compare $build with $host, and > tell the vxworks folks to incant: > > configure --host=arch-wrs-vxworks > > instead of > > configure --target=arch-wrs-vxworks > > Also, I bet it matters exactly what version of autoconf I'm using, huh? Yeah, get the most recent CVS version. You should not need to compare any options to figure out if cross compilation is requested, there is a variable called cross_compiling that will be set to "yes" if the user passed --host=... and "no" otherwise. Please post a note to the list if there is anything that is still confusing about this. It should be easy to understand as long as we explain it properly. Mo DeJong Red Hat Inc
autohead error when trying to build gcc
I tried using the new autoheader with gcc and got this error. cd ../../egcs/gcc && autoheader /usr/local/project/install/autotools/bin/autoheader: N: No such file or directory autoheader: No template for symbol `HAVE_LONG_DOUBLE' make[1]: *** [../../egcs/gcc/cstamp-h.in] Error 1 make[1]: Leaving directory `/mnt/image/build_egcs/gcc' make: *** [all-gcc] Error 2 A note about this macro in the ChangeLog states: Removed their autoheader template. They are now documented with their own AC_DEFINE. Any idea how I should go about fixing this? Mo DeJong Red Hat Inc
Something went wrong with the latest patches.
I tried to use the latest CVS version of autoconf with the
current CVS version of libtool, and it looks like something
got broken.
libtool ml branch with autoconf from the 25th.
cd libtool
./bootstrap
tests/Makefile.am:12: warning: automake does not support conditional
definition
of CXX_TESTS in TESTS
configure.in: 33: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
configure.in: 10: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
configure.in: 14: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
./bootstrap: tagdemo: No such file or directory
cat: ../libtool.m4: No such file or directory
aclocal: configure.in: 36: macro `AM_PROG_LD' not found in library
aclocal: configure.in: 38: macro `AM_PROG_NM' not found in library
tests/Makefile.am:12: warning: automake does not support conditional
definition
of CXX_TESTS in TESTS
(The ./configure generated does not run, but at least it generated
the file).
libtool bootstrap with current CVS version of autoconf.
./bootstrap
tests/Makefile.am:12: warning: automake does not support conditional
definition
of CXX_TESTS in TESTS
/usr/local/project/install/autotools/bin/autoheader: unexpected EOF while
lookin
g for ``'
/usr/local/project/install/autotools/bin/autoheader:
/tmp/ah7973/traces.sh: line
276: syntax error
configure.in: 33: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
configure.in:36: /usr/bin/m4: Bad regular expression: `# These are sane
defaults
that work on at least a few old systems.
# {They come from Ultrix. What could be older than Ultrix?!! ;)}
changequote(,)dnl
# Character class describing NM global symbol codes.
...
It goes one like that and does not generate a working ./configure.
Mo DeJong
Red Hat Inc
Re: Arrange for --build to default to --host
On 26 Jun 2000, Alexandre Oliva wrote: > Here's a patch that implements my proposal regarding the handling of > --build/--host options, assuming that Mo's patch makes it. Ok to > install? So to do a cross build I would need to give both --build and --host? Could there at least be some sort of AC_DONT_USE_HOST_KLUDGE macro that I could put into a new configure.in so that new programs do not need to be burdened by this crufty old stuff? Mo DeJong Red Hat Inc
Re: Arrange for --build to default to --host
On 26 Jun 2000, Alexandre Oliva wrote: > We might also set cross_compiling=maybe if --host is specified but > --build isn't, and then use the original cross_compiling test to > decide. But the old cross compile test did not work on systems where rld did not know how to find a lib the compiler linked to. This made it think it was cross compiling when in fact it was not. That, combined with problems with macros that do not work for a cross compile (like the big endian test) leads to very confused users and bug reports that we just don't need. > > Could there at least be some sort of AC_DONT_USE_HOST_KLUDGE > > macro that I could put into a new configure.in so that new > > programs do not need to be burdened by this crufty old stuff? > > I wouldn't vote against such a macro :-) I don't like the old way because it is a huge mess, but if there were a way to avoid the mess in new scripts I guess I could live with that. How about another option? Why don't we just skip a 2.5 release and call it 3.0? A new "major" version would be the perfect place to put in a fix for a long-standing bug like this. Lets face it, autotools releases only happen every year or two. If we don't make this --host change now, both automake and libtool will keep using the old way for many years to come. Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
On 26 Jun 2000, Akim Demaille wrote: > > | On Jun 19, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > | > I'm sorry, but I disagree. The only sane and simple definition of > | > cross-compilation is when --host is specified. > | > | It might be simple, but I'm not sure it's sane. If host and build are > | identical, it doesn't make sense to assume we're cross-compiling. > > I'm really annoyed by this, but it seems I'm the only one to be > bugged. So I OK the patch :(. Are you talking about the patch I sent in to avoid a cross compile if the same --build and --host are given? > | > For instance you might be willing to use --host = --build just to > | > check how your configure behaves in a (comfortable) > | > cross-compilation situation. > | > | I don't buy that. I could just specify any other arbitrary --host to > | check how configure would behave, or specify a minimally different > | --build system. > > So you have to know what system is close to the system you run, and > you need to have a system that has such a sibling. I don't like host > = build because the whole problem with the previous version of > Autoconf was that you had no control over cross_compiling. Now you > have a perfectly clear control over it: --host. In this case, I don't think anyone would really expect --build=FOO --host=FOO to do a cross compile. ... > I'm asking the question again: can't we enable that stuff only when > given a special option such as --with-old-machine-options-semantics or > whatever? Your proposal is a step backwards into the dark side of > cross compilation (I understand the pressure you face), but the > solution you propose does not give guarantees we will be cleaned from > this. It is not enough temporary. > > Or an ennvar? > > I also proposed that cross_compiling would be imported from the env, > isn't this enough for people to make the transition? > > And what about the wrapper proposal? > > I understand this. But really, can't we have a wrapper for them? We > are destroying the simplicity, the evidence of the current > implementation, which results in, again, obscure things. For > instance, build should *not* default to host. I thought there was already a switch for cygnus behavior. --cygnus assume program is part of Cygnus-style tree Would it be possible to put this old style --host is really --build stuff into the set of options activated when --cygnus is passed in? Mo DeJong Red Hat Inc
Re: Something went wrong with the latest patches.
I can bootstrap and configure libtool now!
% ./bootstrap
tests/Makefile.am:12: warning: automake does not support conditional
definition
of CXX_TESTS in TESTS
autoheader: config.h.in is unchanged
configure.in: 33: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
configure.in: 10: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
configure.in: 14: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
configure.in: 51: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
% cd ../build/libtool
% ~/project/libtool/configure --prefix=/home/mo/project/install/autotools
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
...
( Score! This next bit is what was failing )
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
...
% make
% make install
It worked!
Thanks Akim.
Mo DeJong
Red Hat Inc
Re: --host => cross breaks GCC builds
On 26 Jun 2000, Alexandre Oliva wrote: > On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > > > I thought there was already a switch for cygnus behavior. > > > --cygnus assume program is part of Cygnus-style tree > > I've never seen this option, and it doesn't seem to be accepted by any > autoconf-generated `configure' script. Oh, perhaps it only applies to automake. Here is the description from automake.info-1. `--cygnus' Causes the generated `Makefile.in's to follow Cygnus rules, instead of GNU or Gnits rules. For more information, see *Note Cygnus::. > > Would it be possible to put this old style --host is really > > --build stuff into the set of options activated when --cygnus > > is passed in? > > Maybe we should not assume --build when --host is given, just warn > instead. This would work under the assumption that people running > configure interactively don't often specify --host=TRIPLET, but rather > just TRIPLET, which would work in the new set-up too. I.e., your > patch for $host_alias != $build_alias would be enough. Do you mean warn that --host will do a cross compile or warn that it will not do a cross compile? By the way, my patch was not to test if $host_alias != $build_alias, it was a test to see if they were exactly the same and only when --host=TRIPLE was given. if test "x$host_alias" = "x" || test "$host_alias" = "$build_alias" ; then cross_compiling=no ac_tool_prefix= else cross_compiling=yes ac_tool_prefix=$host_alias- fi Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
On 26 Jun 2000, Alexandre Oliva wrote: > > I don't buy that: nobody will never change anything in their scripts, > > If they won't change their scripts, then it's their fault. By warning > in advance, we're exempting ourselves from being blamed for the change. That is an interesting point. Folks that are used to the current way will blame anyone that makes a change. It does not really matter what the change is, it will "just be wrong". New users will never know the pain of the old way, so they will neither blame nor thank you. The question you have to ask yourself is who do you want to serve and what is best for everyone in the long run. > > Sorry, but this is what I call confusing! > > It may be confusing for *you*, but I'm pretty sure it won't be > confusing for 99% of the autoconf users out there. People hardly > understand the difference between --build and --host, and this warning > will hopefully get them to read the manual, and then they'll learn > about the change in behavior and the real difference between these > flags. I have to chime in on this one because I was one of those new users just a couple of months ago. I did not understand the difference between --build and --host, I read the manual (it did not help much), I looked at examples on the web and found that some people were using --target instead of --host. All in all it was really confusing. The new way seems to be more straightforward (IMHO). The part that most perplexed me were the comments telling me that --build was almost never used, when to do a cross it seems I would need to use --build. > > And you are rejecting the fact that you don't need to specify > > --build, you just need --host. This is a huge step backwards! > > We may have an `I-know-what-I'm-doing' option, such as --Host, for > example. What about a new option --xhost=TRIPLE? That way it would be really clear that you would use this option to do a cross compile for the given host. > > I'm asking the question again: can't we enable that stuff only when > > given a special option such as --with-old-machine-options-semantics or > > whatever? > > I'll answer again: because this wouldn't solve the problem at hand. > There are dozens of scripts and manuals and people out there that > expect --host to set the default for --build. These people should be > warned in advance that they should now be specifying --build to > accomplish that. This will give everybody time to modify their > scripts and manuals, and to start using the new behavior. In fact, > the change that has already been installed in autoconf is incompatible > with the GNU Coding Standards! > http://www.gnu.org/prep/standards_42.html#SEC42 Actually, the GNU coding standards you mention could be read either way. The only time --build is mentioned is during a discussion of bootstrapping a cross-compiler which is something most people are not going to do. The GNU documentation only mentions --host in relation to cross compiling a regular package, so one could argue that the new approach conforms to the GNU standards. The way to build a cross-compiler, cross-assembler, or what have you, is to specify the option `--host=hosttype' when running configure. This specifies the host system without changing the type of target system. The syntax for hosttype is the same as described above. Bootstrapping a cross-compiler requires compiling it on a machine other than the host it will run on. Compilation packages accept a configuration option `--build=hosttype' for specifying the configuration on which you will compile them, in case that is different from the host. See what I mean? Mo DeJong Red Hat Inc
Problem with CVS autoconf + automake + libtool
Sorry for the cross post, but I am not sure if this is a problem with autoconf or automake. I am trying to update the build system for the SDL cross platform graphics library but I am getting the following error. When running autoconf. autoconf: undefined macros: ***BUG in Autoconf--please report*** AM_DEPENDENCIES This macro seems to show up in aclocal.m4 (that is created by automake right). % grep AM_DEPENDENCIES * aclocal.m4: [AM_DEPENDENCIES(CC)], aclocal.m4: defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])])dnl aclocal.m4: [AM_DEPENDENCIES(CXX)], aclocal.m4: defn([AC_PROG_CXX])[AM_DEPENDENCIES(CXX)])])dnl aclocal.m4:dnl AM_DEPENDENCIES(NAME) aclocal.m4:AC_DEFUN(AM_DEPENDENCIES,[ aclocal.m4:dnl This macro is AC_REQUIREd in AM_DEPENDENCIES configure:AC_LIBTOOL_CXXAM_DEPENDENCIES(CXX) configure:AC_LIBTOOL_CXXAM_DEPENDENCIES(CXX) Any ideas? Mo DeJong Red Hat Inc
Re: Autoconf 2.14 breaks certain uses of configure
> So I guess this is an improvement. One problem at a time. > > However, I must say, I do NOT like it changing "i386-linux" to > "i386-pc-linux-gnu". That is not what I typed in. If I want to override > it, I want to damn well override it. > > mrc Did you try "./configure --build=i386-linux" ? That should do what you want. Mo DeJong Red Hat Inc
Regualar compiler also prints a bunch of (cached) values
I just noticed that even for a native build, the change to AC_CHECK_TOOLS will print out a bunch of ugly cached messages. checking for g++... g++ checking for c++... (cached) g++ checking for gpp... (cached) g++ checking for aCC... (cached) g++ checking for CC... (cached) g++ checking for cxx... (cached) g++ checking for cc++... (cached) g++ checking for cl... (cached) g++ checking for KCC... (cached) g++ checking for RCC... (cached) g++ checking for xlC_r... (cached) g++ checking for xlC... (cached) g++ checking for g++... (cached) g++ This is really ugly! Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
On 28 Jun 2000, Akim Demaille wrote: > OK, I see. I was still under the impression that Cygnus was wrapping > the trees, I had not understood users were likely to assemble trees. When a user downloads gcc, it already has a configure script that was generated and checked into the CVS. Besides, how would a user regen a configure script without having autoconf installed? If you are talking about a regen with an older version of autoconf then folks could not do that, but I do not see what this has to do with anything. > OK, I'm ``convinced'' :) > > Alexandre> Yahh > > Hey, wait that I send the message before answering! :) > > Do you think there is really a chance that in a not so distant future, > in this galaxy, we will reimplement the behavior we have in CVS? I > fear we will never be able to, for instance because of the build > defaulting to host. If you go back to the old way of doing it, then I doubt it will ever get changed. Folks are going to trot out the same old "It is just wrong to change it, we have been doing it this way for years" argument and you are right back where you started. Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
On 28 Jun 2000, Alexandre Oliva wrote: > On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > > > Now I understand Cygnus does not package forest > > Cygnus does. It is GNU that doesn't. So this change is more > important for GNU developers in general than for Cygnus' customers. > I'm sorry I didn't make this clear from the beginning. I hadn't > realized it myself when I re-started this discussion. Sorry, but I just do not see the logic in that argument. If some tool has not been updated for 5 years, what are the chances someone if going to switch to the new autoconf and expect everything to work exactly the same way? As far as our tree goes, the only way this argument makes sense is if we import a 5 year old package into devo. In that case, it is someone at cygnus that will need to do the work to fix the old configure script so that it works with the new autoconf. I can see the logic in the argument that we (cygnus) would not want people to use 2.13 in some places and 2.50 in other places of out own tree, but that just means that we would need to update all the configure scripts in devo at once or just keep using 2.13 for some amount of time and then switch them all over to 2.50. What problem is not solved by either of these approaches? > Mo> If you go back to the old way of doing it, then I doubt it will > Mo> ever get changed. > > > I share you pessi^H^H^H^H^H impression. > > :-) > > I too fear we'll never be able to drop the old behavior, since there > are packages out there that haven't had update releases for 5 years or > more. We shouldn't expect such packages to disappear, so, it would > not be unreasonable to retain some behavior in common with them. But > I probably wouldn't fight for that in, say, two years' time. I don't understand how you can make the claim that switching back is "more important for developers in general than for Cygnus". I can see how it is important to use, it means we will not have to update any configure scripts for another 2 years. Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
> It's the converse: tools that configure and build other tools, such as > RPM, may prefer a consistent interface to build pretty much > everything, instead of having to customize its behavior for old > packages. But the importance of the backward-compatible change > for GNU projects doesn't have much to do with such outdated packages. > It has to do with people being able to mix-and-match the next few > releases of GCC, binutils, GDB, etc, without worrying whether they've > been released with the next autoconf or with the current one. Lets not bring RPM into this (ask angela how much she likes RPM from the EDK project if you want to know why ). ... > > I can see how it is important to use, it means we will > > not have to update any configure scripts for another 2 years. > > It means we'll have 2 years or so to update our scripts and > documentation, not that we won't have to change them during that > period. But, there is nothing to update! We have already addressed the issue of toplevel configure passing both --build and --host down to sub-configures. The only issue that remains is the case where --host (and only --host) is passed to top level configure. The following would work with the old and new --host semantics, in either case it would do a cross compile. ./configure --build=i386-linux --host=i386-mingw The only case we are talking about here is when --host is passed to the top level configure. (not a cross compile with the old semantics) ./configure --host=i386-linux The old semantics would use this value of --host for both --build and --host. The only change that the new semantics would require is for the user to pass --build instead of --host at configure/build time. ./configure --build=i386-linux I just don't see why this is such a big deal. Why can't we just use the new --host semantics and print a warning so that folks who are used to the old semantics will not accidently activate a cross compile? like so: ./configure --host=i386-mingw32msvc checking build system type... i686-pc-linux-gnu checking host system type... i386-pc-mingw32msvc configure: WARNING: Now cross compiling from i686-pc-linux-gnu to i386-pc-mingw32msvc, if you intended to set the build triple, use --build. ... I still do not understand why this is not acceptable, why would people be more willing to pass --build instead of --host two years from now? Do we just hope that they are going to get sick of messages like: "warning: You passed --host and we are going to change what this argument does in a couple of years. You will thank us when we do because you will not have to see this silly warning all the time". Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
> Wednesday, May 1st 2002 on [EMAIL PROTECTED] > > Back-war Killer Oliva > > vs > > Host-ile Froggy Akim > > Will Oliva keep his World Championship title? An autotools death match? I would buy a TV to see that! The other one I would like to see is: (Old School) RMS vs. (Perl loving) T. Tromey The showdown: Will automake be rewritten in guile? Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
On 28 Jun 2000, Alexandre Oliva wrote: > On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > > > But, there is nothing to update! We have already addressed the > > issue of toplevel configure passing both --build and --host > > down to sub-configures. > > Indeed. But there's a lot of documentation to be updated, so that > people will use --build where appropriate. The "we would need to change documentation" argument is a red herring. Most of the documentation (like the GNU coding standards) either have incorrect info or no info on how to cross compile a package. If you are talking about our internal cygnus documentaiton, then that is another story, but that has nothing to do with everyday users of autoconf. > And we also have to update > the top-level configure to reflect the new semantics of --build and > --host. Is that the main argument for reverting back to the old --host semantics? Just so that the cygnus toplevel configure script does not need to get updated to match the changed semantics of CVS autoconf? It just seems like we are holding back real progress in autoconf just so that we can avoid doing some work to update our custom toplevel configure. Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
Boy, this is funny. While this whole --host flame was raging, I came across this note on the mingw mailing list. This is just further proof that new users do not understand the old cross compile semantics and that the docs don't help much. Mo DeJong Red Hat Inc Hi All, I noticed the other day that some kind soul has ported the mingw environment to FreeBSD. This is awesome. However, I'm not sure I understand how to build win32 programs from FreeBSD. I know that when I want to build something on a windows box, I type g++ -o test.exe test.cpp -mwindows to get a windows app. How would I do this in unix? Would I have to use --target= If so, what would the target equal? /mtb
Re: --host => cross breaks GCC builds
> > Is that the main argument for reverting back to the old > > --host semantics? > > Nope. There are several arguments. Please read all this thread > carefully. I have been following this thread :) The problem of passing options down to sub configures is solved by my patch, right? The only other issue is the change that required the user to pass --build instead of --host when only one is given on the command line. Are there any other issues still unresolved? If you are dead set on reverting to the old behavior, will there at least be some sort of shortcut that can be used with new configure scripts so that a user can tell configure to do a cross compile without giving the entire --build triple for the build machine? I saw something like this mentioned: ./configure --host=i386-mingw32 cross_compiling=1 That would be a lot easier than having to give just to do a cross compile: ./configure --build=i686-pc-linux-gnu --host=i386-mingw32 Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
> When --host is given, we should not just assume we've got a cross > compiler. Instead, we test the compiler we've got, and decide whether > it's a cross compiler or not. ... > The only concessions for backward compatibility we're making is that > --host alone will cause a cross-compilation situation to be > auto-detected, even though $build will be set to host, not to > `config.guess'. But, as I said, there'd be no way to guess --build > correctly, so we might as well bail out when we detect a cross > compiler and --build wasn't specified. ... > > If you are dead set on reverting to the > > old behavior > > I'm not. I want both behaviors, so that people can make the > conversion when it is more convenient for them, and we can have some > time for the world to adapt to the change. And I hope my patch shows > it is possible to deliver that. ... > Sure: just run `configure --host=i386-mingw32'. It will work, just as > before. The problem is that, just as before, you won't have `--build' > set properly. > > You can set: > > % b=--build=`config.guess` > > and run: > > % ./configure $b --host=i386-mingw32 > > There's no way for configure to correctly guess the build platform, in > general, when it's told to use a cross compiler. That is still really lame. Why can't we just switch the value of $build over to the output of config.guess for the build system when we try to detect a cross compiler and the resulting executable can not be run? That would give us the "best of both worlds" solution that you mentioned. That would let me run the following and have it detect the build and host system. ./configure --host=i386-mingw32 It is not as clean as the original solution but it should maintain backward compatibility and let people use both the old and new semantics. Mo DeJong Red Hat Inc
Re: --host => cross breaks GCC builds
On 28 Jun 2000, Alexandre Oliva wrote: > On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > > > Why can't we just switch the value of $build over to the output of > > config.guess for the build system when we try to detect a cross > > compiler and the resulting executable can not be run? > > Compare the output of `config.guess' with that of > `CC=/path/to/cross-gcc config.guess' on a couple of different > platforms and you'll see what I mean. What is wrong with just running config.guess without knowing anything about the cross compiler? % ./config.guess i686-pc-linux-gnu We could add something like this after the cross detect step: if test "$cross_compiling" = yes && test "$build_alias" = "" ; then build=`$ac_config_guess` fi Mo DeJong Red Hat Inc
Should ./config.status --recheck rerun ./config.status?
Hi all. I think the following seem a little off. % ./config.status --recheck ... creating ./config.status % ./config.status creating Makefile creating tkConfig.sh I think ./config.status --recheck should also regenerate the Makefile from .in file. What do you think? Mo DeJong Red Hat Inc
Should gcc use the -pipe option by default?
Hi all. I have noticed that there are a number of packages that include extra code to test for and enable the -pipe option to gcc. I think it might be a good idea to add the -pipe option to the default CFLAGS if gcc is detected and the -pipe option is supported. What do you think? Mo DeJong Red Hat Inc
This configure.in script does not work with autoconf 2.14
Hi all. I seem to have run into a really strange error that only shows up with the CVS autoconf. Here is what it printed when I run the configure script. checking for BSDgettimeofday... home/mo/project/tcl/unix/configure: /home/mo/project/tcl/unix/configure: line 6895: syntax error: unexpected end of file I used the good old binary search with an echo command and found the general location of the problem. Here is the output with the additional debug statements. START gettimeofday TESTS! checking for BSDgettimeofday... EOF gettimeofday TESTS! POST COMPILE gettimeofday TESTS! no PRE TEST COMPILE gettimeofday TESTS! ac_cv_func_BSDgettimeofday is "no" /home/mo/project/tcl/unix/configure: /home/mo/project/tcl/unix/configure: line 6896: syntax error: unexpected end of file Here are the commands from configure (I added the echo commands). echo "PRE TEST COMPILE gettimeofday TESTS!" echo "ac_cv_func_BSDgettimeofday is \"$ac_cv_func_BSDgettimeofday\"" if test $ac_cv_func_BSDgettimeofday = yes; then echo "INSIDE TRUE gettimeofday TESTS!" cat >>confdefs.h <<\EOF #define HAVE_BSDGETTIMEOFDAY 1 EOF else echo "INSIDE FALSE gettimeofday TESTS!" echo "configure:4005: checking for gettimeofday" >&5 It does not seem to make it into the true of false branch for this if statement. I am really stumped here. If I run autoconf 2.13 over this exact same configure.in I get a configure script that runs without problems. Does anyone know what might be going on here? Mo DeJong Red Hat Inc
Re: Should gcc use the -pipe option by default?
On Mon, 3 Jul 2000 [EMAIL PROTECTED] wrote: > On Mon, 3 Jul 2000, Mo DeJong wrote: > > > Hi all. > > Hi. > > > I have noticed that there are a number of packages that > > include extra code to test for and enable the -pipe > > option to gcc. I think it might be a good idea to add > > the -pipe option to the default CFLAGS if gcc is detected and > > the -pipe option is supported. What do you think? > > Just yesterday I set out to write my own. Could you be so kind as to point > me to a couple of existing versions? Thanks. Sure, but I would rather see this in autoconf :) if test -n "$GCC"; then AC_MSG_CHECKING([if the compiler understands -pipe]) OLDCC="$CC" CC="$CC -pipe" AC_TRY_COMPILE(,, AC_MSG_RESULT(yes), CC="$OLDCC" AC_MSG_RESULT(no)) fi Mo DeJong Red Hat Inc
Re: This configure.in script does not work with autoconf 2.14
On 3 Jul 2000, Akim Demaille wrote:
> You didn't send the input, but my bet is that you have nested two here
> docs with the same tags. You might not even know this since Autoconf
> stupidly uses EOF at zillions of different places. I plan to change
> them all into ACEOF or alike.
>
> But then, maybe that's another issue :)
Here is the input from configure.in.
AC_CHECK_FUNC(BSDgettimeofday, AC_DEFINE(HAVE_BSDGETTIMEOFDAY),
AC_CHECK_FUNC(gettimeofday, , AC_DEFINE(NO_GETTOD)))
AC_MSG_CHECKING([for gettimeofday declaration])
AC_EGREP_HEADER(gettimeofday, sys/time.h, AC_MSG_RESULT(present), [
AC_MSG_RESULT(missing)
AC_DEFINE(GETTOD_NOT_DECLARED)
])
Here is what appears in the configure file. I really
have no idea what the diff between EOF and \EOF is.
echo "configure:3955: checking for BSDgettimeofday" >&5
echo $ECHO_N "checking for BSDgettimeofday... $ECHO_C" >&6
if test "${ac_cv_func_BSDgettimeofday+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
cat >conftest.$ac_ext <
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char BSDgettimeofday ();
char (*f) ();
int
main ()
{
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_BSDgettimeofday) || defined (__stub___BSDgettimeofday)
choke me
#else
f = BSDgettimeofday;
#endif
;
return 0;
}
EOF
if { (eval echo configure:3989: \"$ac_link\") >&5; (eval $ac_link) 2>&5;
} && test -s conftest${ac_exeext}; then
ac_cv_func_BSDgettimeofday=yes
else
echo "configure: failed program was:" >&5
cat conftest.$ac_ext >&5
ac_cv_func_BSDgettimeofday=no
fi
rm -f conftest*
fi
echo "configure:3998: result: $ac_cv_func_BSDgettimeofday" >&5
echo "${ECHO_T}$ac_cv_func_BSDgettimeofday" >&6
if test $ac_cv_func_BSDgettimeofday = yes; then
cat >>confdefs.h <<\EOF
#define HAVE_BSDGETTIMEOFDAY 1
EOF
else
echo "configure:4005: checking for gettimeofday" >&5
echo $ECHO_N "checking for gettimeofday... $ECHO_C" >&6
if test "${ac_cv_func_gettimeofday+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
cat >conftest.$ac_ext <&5
echo $ECHO_N "checking for gettimeofday declaration... $ECHO_C" >&6
cat >conftest.$ac_ext <
EOF
if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
egrep "gettimeofday" >/dev/null 2>&1; then
echo "configure:4024: result: present" >&5
echo "${ECHO_T}present" >&6
else
echo "configure:4027: result: missing" >&5
echo "${ECHO_T}missing" >&6
cat >>confdefs.h <<\EOF
#define GETTOD_NOT_DECLARED 1
EOF
fi
rm -f conftest*
Mo DeJong
Red Hat Inc
Re: Should gcc use the -pipe option by default?
On Mon, 3 Jul 2000 [EMAIL PROTECTED] wrote: > On Mon, 3 Jul 2000, Mo DeJong wrote: > > > if test -n "$GCC"; then > > AC_MSG_CHECKING([if the compiler understands -pipe]) > > OLDCC="$CC" > > CC="$CC -pipe" > > AC_TRY_COMPILE(,, > > AC_MSG_RESULT(yes), > > CC="$OLDCC" > > AC_MSG_RESULT(no)) > > fi > > My concern is, on some platforms gcc -pipe just silently fails to create > an output file but does not return an error code. That sounds like the sort of "feature test" that autoconf should be doing to make sure -pipe can be used. Could you write up a macro to detect this case? You should also submit a gcc bug report on this problem. Mo DeJong Red Hat Inc
Re: Should gcc use the -pipe option by default?
On 3 Jul 2000, Alexandre Oliva wrote: > On Jul 3, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > > > I think it might be a good idea to add the -pipe option to the > > default CFLAGS if gcc is detected and the -pipe option is > > supported. What do you think? > > I think this should not be done by default. -pipe is more > CPU-intensive than regular builds, so it should be up to the builder > to decide whether to use it or not. -pipe may work fine on a > developer's high-end system, but not on Joe User's low-end machine, > nor in Joe Power User's case of building with `make -j8' to make use > of his SMP machine. I think the default should be set for the most common case. The most common case is someone building on a reasonable machine. If you have a really lame machine or a supper SMP machine, then you may need to use something other than the default. If it makes the build go faster for 99% of the folks out there, we should use it. If you just add a AC_USE_PIPE_WITH_GCC macro, who is going to know about it? People would need to add that macro to old configure.in files to see any improvement. > However, since there's demand for such a macro, we could supply one > that would refrain from adding -pipe, even if supported, when a > configure option such as --disable-pipe is given. But IMHO this macro > should not be used by default; it's only for those developers that > *think* they know better than their users, and we should make it clear > in the docs that this macro is not recommended in general. Why not make -pipe the default when gcc is detected and add a --disable-pipe option? That would make it easy to turn off -pipe if someone wanted to build in some strange way. The only way defaults are useful is that are actually set as the default :) If there is a problem with the -pipe option under cygwin, then lets just not use it under cygwin. Mo Dejong Red Hat Inc
Re: Should gcc use the -pipe option by default?
On 4 Jul 2000, Alexandre Oliva wrote: > On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > > > If it makes the build go faster for 99% of the folks out there, we > > should use it. > > Does it? I really don't know. Taking your argument further, why > shouldn't -pipe be the default in GCC when it is supported? This > wouldn't require any changes in autoconf. That seems like a good question to post to a gcc list. Perhaps this will be added to gcc 3.0. That still does not help all the folks running onlder versions of gcc. This change would need to be added to autoconf if it were to do any good in the next couple of years. Mo DeJong Red Hat Inc
Patch for new --build and --host semantics
I took a pass at the most recent --build --host stuff in the CVS version and it looks like it is *almost* ready. The first thing we to do was change the warning message. It is confusing and does not really tell me that things could still change based on what is detected at runtime. Here is the change I propose. Old: ./configure --host=i386-mingw32msvc configure: WARNING: Did you mean --build instead of --host? Assuming you did. configure: WARNING: If not, please specify both --build and --host. ... checking build system type... i686-pc-linux-gnu checking host system type... i386-pc-mingw32msvc checking for i386-mingw32msvc-g++... i386-mingw32msvc-g++ checking whether the C++ compiler works... no yes checking whether we are using GNU C++... yes checking whether i386-mingw32msvc-g++ accepts -g... yes New: ./configure --prefix=/tmp/jikes_Xmingw --host=i386-mingw32msvc configure: WARNING: For backwards compatibility, --build will be set to --host if a cross compiler can not be found ... checking build system type... i686-pc-linux-gnu checking host system type... i386-pc-mingw32msvc checking for i386-mingw32msvc-g++... i386-mingw32msvc-g++ checking whether the C++ compiler works... yes checking whether we are using GNU C++... yes The next problem is that when a cross compiler is not detected, we need to reset --build to --host. I also a printout of the cross_compiling variable and the reset --build (if it was actually reset). Old: ./configure --host=i386-pc-linux-gnu ... checking build system type... i686-pc-linux-gnu checking host system type... i386-pc-linux-gnu ... checking for i386-pc-linux-gnu-g++... no checking for i386-pc-linux-gnu-c++... no ... checking for g++... g++ checking whether the C++ compiler works... yes checking whether we are using GNU C++... yes New: ... checking build system type... i686-pc-linux-gnu checking host system type... i386-pc-linux-gnu checking for i386-pc-linux-gnu-g++... no checking for i386-pc-linux-gnu-c++... no ... checking for g++... g++ checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking reset of build system type... i386-pc-linux-gnu checking whether we are using GNU C++... yes Note how the build system is initially incorrect but after the cross compiler detection step it gets fixed. I also fixed the bug that caused printing of multiple cache values when searching for a compiler in the native case. Here is the full patch. Index: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.712 diff -u -r1.712 ChangeLog --- ChangeLog 2000/07/03 10:41:30 1.712 +++ ChangeLog 2000/07/04 09:25:55 @@ -1,3 +1,12 @@ +2000-07-04 Mo DeJong <[EMAIL PROTECTED]> + + * acgeneral.m4 (_AC_INIT_PARSE_ARGS, AC_CHECK_TOOLS): Change + warning message printed when only --host is given. Fix printing + of multiple compiler cache values, use PATH argument. + * aclang.m4 (AC_LANG_COMPILER_WORKS): Set --build to --host if + test for cross compiler fails and only --host is given. Print + the cross compile status, print the --build if it was reset. + 2000-07-03 Akim Demaille <[EMAIL PROTECTED]> * acgeneral.m4 (_AC_INIT_PARSE_ARGS) <-C>: Use `./config.cache', not Index: acgeneral.m4 === RCS file: /cvs/autoconf/acgeneral.m4,v retrieving revision 1.500 diff -u -r1.500 acgeneral.m4 --- acgeneral.m42000/07/03 10:41:30 1.500 +++ acgeneral.m42000/07/04 09:25:59 @@ -1567,8 +1567,8 @@ if test "x$host_alias" != x; then if test "x$build_alias" = x; then cross_compiling=maybe -AC_MSG_WARN([Did you mean --build instead of --host? Assuming you did.]) -AC_MSG_WARN([If not, please specify both --build and --host.]) +AC_MSG_WARN([For backwards compatibility, --build will be set to --host +if a cross compiler is not detected]) elif test "x$build_alias" != "x$host_alias"; then cross_compiling=yes fi @@ -2218,8 +2218,8 @@ else AC_MSG_RESULT(ok) fi -ac_cv_host_system_type=$host ac_cv_build_system_type=$build +ac_cv_host_system_type=$host ac_cv_target_system_type=$target[]dnl ]) @@ -2921,11 +2921,11 @@ AC_DEFUN([AC_CHECK_TOOLS], [for ac_prog in $2 do - AC_CHECK_PROG([$1], $ac_tool_prefix$ac_prog, $ac_tool_prefix$ac_prog, [$3]) - test "$$1" != "$3" && break + AC_CHECK_PROG([$1], $ac_tool_prefix$ac_prog, $ac_tool_prefix$ac_prog,, [$4]) + test "$$1" != "" && break done -if test "$$1" = "$3"; then - AC_CHECK_PROGS([$1], [$2], [$3]) +if test "$$1" = ""; then + AC_CHECK_PROGS([$1], [$2], [$3], [$4]) fi ])# AC_CHECK_TOOLS Index: aclang.m4 === RCS fil
Re: autoupdate test failure
On 4 Jul 2000, Akim Demaille wrote: > >>>>> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes: > > Patrick> I'm happy to try suggestions. > > Hi! > > Thanks for the report. The problem is most probably that your sed is > not GNU sed. For the time being I don't know too well what to do: get > rid of this limitation (but then I know that anyway autoupdate is > putting a very high pressure on sed so it *will* break on some other > system), or just rewriting autoupdate in Perl. > > Or Python :) Don't forget Tcl :) The next release of Tcl is going to add OO support. Those python folks are going to have to quit with the "but our tool has OO" stuff. Mo DeJong Red Hat Inc
Re: Patch for new --build and --host semantics
On 4 Jul 2000, Alexandre Oliva wrote: > On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > > > configure: WARNING: For backwards compatibility, --build will be set to --host > > if a cross compiler can not be found > > This is not true. Akim committed the patch without updating the > documentation. Now, --build is guessed unless explicitly specified. I do not think that is what we agreed to. If you don't set $build to the value passed as --host in the case where --host is the only argument and a cross compiler is not found, then there is no backwards compatibility. That was kind of the point of reverting back to the old system to begin with. Also note that this warning is only printed in the case where only --host is passed. > If --host is specified but --build isn't, we'll enter > cross-compilation mode if an executable generated by the compiler > can't be run. If both --host and --build are specified, and they're > different, we enter cross compilation mode unconditionally. If > they're equal, or not specified, we will reject a cross compiler. My patch follows those semantics, except in the case where a cross compiler is not detected, and then it reverts to the old semantics. I am not sure what you mena by "reject a cross compiler". > > The next problem is that when a cross compiler is not > > detected, we need to reset --build to --host. > > Why?!? I can't believe what I am reading. Are you now saying that backward compatibility with the old --build --host semantics is a bad thing? The old semantics would set $build to i386-pc-linux with the following: ./configure --host=i386-pc-linux Mo DeJong Red Hat Inc
Re: Patch for new --build and --host semantics
On 4 Jul 2000, Alexandre Oliva wrote: > Can you point to any configure.in code for which this makes any > difference? Remember, we're just not setting build_alias=$host_alias > any more. We won't be assuming cross-compilation just because they > happen to be different, in this case. There is none, only what the user passes makes a diff. > The point was to not assume cross-compilation just because --host was > specified. Now this is accomplished as follows: That is fine with me. In fact that is much less of a "revert" than I thought you were making. > The warning, as it is now, is not perfect, but what you suggest just > doesn't match the current implementation. Agreed, I was under the impression you wanted to still support the old --host sets --build semantics. I guess we can just chalk this one up to mis-communication. > > The old semantics would set $build to i386-pc-linux with the following: > > > ./configure --host=i386-pc-linux > > I understand. But a guessed build probably would be pretty close to > the specified --host, unless you're actually cross-compiling, in which > case having --build guessed is an actual improvement. I don't see > much point in retaining backward compatibility in this case, do you? Nope, this is much cleaner than what I thought we had agreed to. It simply means that people who are used to setting the --build using --host are going to have to change to --build. It also sort of "tosses out" whatever is passed as the argument to --host if it is not used to detect a cross compiler. Mo DeJong Red Hat Inc
Patch for printed messages and AC_CHECK_TOOLS
Ok, here is a patch like the last one except that it does not change anything related to --build and --host. It does improve the warning that gets printed (IMHO) and it fixes a couple of bugs in AC_CHECK_TOOLS and AC_LANG_COMPILER_WORKS. I don't think we want to actually encourage the use of --build=TRIPLE --host=X-TRIPLE when folks can just use --host=X-TRIPLE by itself. Mo DeJong Red Hat Inc (I also attached the patch file, in case that helps) Index: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.713 diff -u -r1.713 ChangeLog --- ChangeLog 2000/07/04 10:34:21 1.713 +++ ChangeLog 2000/07/04 12:28:48 @@ -1,3 +1,11 @@ +2000-07-04 Mo DeJong <[EMAIL PROTECTED]> + + * acgeneral.m4 (_AC_INIT_PARSE_ARGS, AC_CHECK_TOOLS): Change + warning message printed when only --host is given. Fix printing + of multiple compiler cache values, use PATH argument. + * aclang.m4 (AC_LANG_COMPILER_WORKS): Print the cross compile + status, fix problem where two results were printed at once. + 2000-07-04 Akim Demaille <[EMAIL PROTECTED]> * acgeneral.m4 (AC_CACHE_LOAD): Be ready to read the cache even Index: acgeneral.m4 === RCS file: /cvs/autoconf/acgeneral.m4,v retrieving revision 1.501 diff -u -r1.501 acgeneral.m4 --- acgeneral.m42000/07/04 10:34:21 1.501 +++ acgeneral.m42000/07/04 12:28:52 @@ -1567,8 +1567,8 @@ if test "x$host_alias" != x; then if test "x$build_alias" = x; then cross_compiling=maybe -AC_MSG_WARN([Did you mean --build instead of --host? Assuming you did.]) -AC_MSG_WARN([If not, please specify both --build and --host.]) +AC_MSG_WARN([If you wanted to set the --build type, don't use --host. +If a cross compiler is detected then cross compile mode will be used.]) elif test "x$build_alias" != "x$host_alias"; then cross_compiling=yes fi @@ -2926,11 +2926,11 @@ AC_DEFUN([AC_CHECK_TOOLS], [for ac_prog in $2 do - AC_CHECK_PROG([$1], $ac_tool_prefix$ac_prog, $ac_tool_prefix$ac_prog, [$3]) - test "$$1" != "$3" && break + AC_CHECK_PROG([$1], $ac_tool_prefix$ac_prog, $ac_tool_prefix$ac_prog,, [$4]) + test "$$1" != "" && break done -if test "$$1" = "$3"; then - AC_CHECK_PROGS([$1], [$2], [$3]) +if test "$$1" = ""; then + AC_CHECK_PROGS([$1], [$2], [$3], [$4]) fi ])# AC_CHECK_TOOLS Index: aclang.m4 === RCS file: /cvs/autoconf/aclang.m4,v retrieving revision 1.35 diff -u -r1.35 aclang.m4 --- aclang.m4 2000/06/30 13:34:38 1.35 +++ aclang.m4 2000/07/04 12:28:53 @@ -471,12 +471,12 @@ define([_AC_LANG_COMPILER_WORKS], [AC_MSG_CHECKING([whether the _AC_LANG compiler works]) AC_LINK_IFELSE([AC_LANG_PROGRAM()], -[# If not cross compiling, check that we can run a simple program. +[# FIXME : these cross compiler hacks should be removed for autoconf 3.0 +# If not cross compiling, check that we can run a simple program. if test "$cross_compiling" != yes; then if AC_TRY_COMMAND(./conftest); then cross_compiling=no else -AC_MSG_RESULT(no) if test "$cross_compiling" = maybe; then cross_compiling=yes else @@ -488,6 +488,8 @@ AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no) AC_MSG_ERROR([_AC_LANG compiler cannot create executables], 77)])[]dnl +AC_MSG_CHECKING([whether we are cross compiling]) +AC_MSG_RESULT($cross_compiling) ])# AC_LANG_COMPILER_WORKS Index: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.713 diff -u -r1.713 ChangeLog --- ChangeLog 2000/07/04 10:34:21 1.713 +++ ChangeLog 2000/07/04 12:28:48 @@ -1,3 +1,11 @@ +2000-07-04 Mo DeJong <[EMAIL PROTECTED]> + + * acgeneral.m4 (_AC_INIT_PARSE_ARGS, AC_CHECK_TOOLS): Change + warning message printed when only --host is given. Fix printing + of multiple compiler cache values, use PATH argument. + * aclang.m4 (AC_LANG_COMPILER_WORKS): Print the cross compile + status, fix problem where two results were printed at once. + 2000-07-04 Akim Demaille <[EMAIL PROTECTED]> * acgeneral.m4 (AC_CACHE_LOAD): Be ready to read the cache even Index: acgeneral.m4 === RCS file: /cvs/autoconf/acgeneral.m4,v retrieving revision 1.501 diff -u -r1.501 acgeneral.m4 --- acgeneral.m42000/07/04 10:34:21 1.501 +++ acgeneral.m42000/07/04 12:28:52 @@ -1567,8 +1567,8 @@ if test "x$host_alias" != x; then if test "x$build_alias" = x; then cross_compiling=maybe -AC_MSG_
Re: How stable is the current CVS version of autoconf?
On Tue, 4 Jul 2000, Harlan Stenn wrote: > Is the present state of the CVS version of autoconf "stable enough" for > production use? > > It looks like a couple of folks are getting ready to start cross-compile > efforts for new releases of NTP, and I need to decide if I should upgrade or > hold still... I can not comment on "how stable" the CVS autoconf (aside from "it works for me") but I can tell you that trying to cross compile with 2.13 made my head hurt. The new cross compile semantics are much easier. The new (easy to remember) slogan for cross compiling is: "To use a hosted cross compiler, just pass --host." Mo DeJong Red Hat Inc
Lots of CFLAGS.
I just noticed that the more I run ./config.status --recheck the more CFLAGS arguments show up in ./configure line that gets rerun. (This is after two re-configures) % make /bin/sh ./config.status --recheck running /bin/sh /home/mo/project/tkgs/configure CFLAGS=-g -O2 CFLAGS=-g -O2 --host=i386-mingw32msvc --with-tcl=/home/mo/project/build/tcl_Xmingw --with-tk=/home/mo/project/build/tk_Xmingw --prefix=/tmp/tkgs_Xmingw --no-create --no-recursion Also, if CFLAGS is not set to anything by the user, why should it get passed into the ./configure on the command line? Mo DeJong Red Hat Inc
RE: Patch for new --build and --host semantics
On Wed, 5 Jul 2000, Bernard Dautrevaux wrote:
> > i) if --host is specified but --build isn't, we use the old
> > compile-link-and-execute test to determine whether we're cross
> > compiling or not
>
> Here I think Mo has bring an interesting, and useful IMNSHO, idea: if --host
> is given AND we can find a compiler named $host_alias-{cc|gcc|c++|g++}, THEN
> we assume cross-compiling, even if $(CC) generates a program that can be
> run; if this compiler is not able to produce a program we should reject it
> (in the proper macro probably).
The problem with that approach is that you never really know if you
found a cross compiler unless you test it. The only way we can test
it is to try to run it. It is really lame, but I don't see how the
situation can be improved. You can't just put code into the
AC_CHECK_TOOLS macro because that macro can be used for other
tools (not just the compiler). The user could also have set
the CC env var to a cross compiler.
> I thing this is very useful, as it does usually not bring backward
> compatibility (I usually do not have an alias i686-unknown-linux-gnu-gcc to
> gcc on mya Linux box) and allo me not to need setting CC to $host_alias-gcc
> AND CC_FOR_BUILD to gcc when I want cross-compiling (which was a desired
> feature).
You don't need to set CC to get a cross compile. The current CVS
version will automatically detect and use a cross triple that
you pass in with the --host argument. End users should see no
difference from the way it worked from last week, only the implementation
has changed to support backwards compatibility in the case that
a cross compiler was not found.
> I think the difference between Mo's idea and your's is that "detecting" a
> cross compiler for Mo is finding $host_alias-gcc while for you it is finding
> a compiler that generates non-executable files...
No the behavior from last week was to always cross compile when --host
is given. Now the behavior is to cross compile when --host is given
and the compiler is a cross compiler. The way you know it is a cross
compiler is the same old "try to run it" test.
Mo DeJong
Red Hat Inc
Re: Patch for new --build and --host semantics
On 5 Jul 2000, Akim Demaille wrote: > >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: > > Alexandre> This is not true. Akim committed the patch without > Alexandre> updating the documentation. > > Right :( Could someone try to fix that? I don't have time now, and > in addition, I feel incompetent. What docs changes are you talking about? The docs should be the same WRT cross compiling. People should still use --host=$TRIPLE to do a cross compile. I don't think we want to even mention the backwards compatibility stuff we put in, old time cross compilers will already know it and we don't want to confuse new users (trust me, it is confusing enough). Mo DeJong Red Hat Inc
Re: MoRe: upgrading to CVS autoconf
On Thu, 6 Jul 2000, Lars J. Aas wrote: > On Thu, Jul 06, 2000 at 02:33:39PM +0200, Lars J. Aas wrote: > : I'm trying to upgrade to CVS autoconf, and I'm wondering if I need > : to upgrade automake, libtool, and m4 at the same time? > > I've upgraded autoconf and automake and m4 to release 1.4o (only > vanilla tool is libtool 1.3.5), and things seems to go fine until I > try to run configure: > > [...] > | checking host system type... i586-pc-linux-gnu > | checking for ranlib... ranlib > | checking for ld used by GCC... /usr/bin/ld > | checking if the linker (/usr/bin/ld) is GNU ld... yes > | checking for BSD-compatible nm... /usr/bin/nm -B > | checking whether ln -s works... yes > | loading cache /dev/null within ltconfig > | ltconfig: you must specify a host type if you use `--no-verify' > | Try `ltconfig --help' for more information. > | configure: error: libtool configure failed > | $ > > What's the deal with this? Am I missing some libtool macro in > configure.in? You need to upgrade to the CVS versions of autoconf, automake, and libtool. You also need to install them in that order to get libtool to bootstrap itself with the new autoconf. It is actually kind of messy, but it does work if you install them in the right order and set the PATH to include the install bin directory. The error you are running into means you are using the old version of libtool with the new version of autoconf and automake, and that don't work. Another approach is to uninstall the old versions of autoconf, automake, and libtool before you begin. Mo DeJong Red Hat Inc
Re: --help message (was: Lots of CFLAGS)
On Thu, 6 Jul 2000, Steven G. Johnson wrote:
> I'd like to chime in with support for documenting a few key environment
> variables in --help.
>
> The single biggest problem I see users having when installing packages ala
> autoconf is that they installed a needed library in some random directory
> (e.g. if they are not root) and so of course configure doesn't find it. I
> see this again and again, both in my own programs and other people's, no
> matter how well I try to document it.
>
> Because of this, I think it is a good idea to document at least LDFLAGS
> ("-L/somedir/lib") and CPPFLAGS ("-I/somedir/include") in the --help,
> perhaps along with CC/CXX/F77 and CFLAGS/CXXFLAGS/FFLAGS. I wouldn't mind
> submitting a patch for that.
>
> Steven
How would you know what directory /somedir is? I could see that it
might make sense to check for ${prefix}/include and ${exec_prefix}/lib
and use those as a default if they exist (and perhaps if they are
not the "regular" default like /usr/local). That way if you have
three packages that want to install into /usr/mydir, and all three
use the same --prefix, then it will just work like magic. But
then again, you could just code that into your own configure.in.
Mo DeJong
Red Hat Inc
Cross compile problem.
I just ran into an error when using the --host=XTRIPLE argument.
I am trying to cross compile with libtool, and it is really
broken to say the least. I tried to work around it by
setting CC to my cross compiler before running ./configure.
setenv CC i386-mingw32msvc-gcc
./configure --host=i386-mingw32msvc
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking build system type... /home/mo/project/tkgs/config.guess:
./dummy-4106:
cannot execute binary file
configure: error: cannot guess build type; you must specify one
So config.guess is getting messed up because it is trying
to use my cross compiler to figure out the build system
type.
I took a peek at the config.guess and found this.
# Use $HOST_CC if defined. $CC may point to a cross-compiler
if test x"$CC_FOR_BUILD" = x; then
if test x"$HOST_CC" != x; then
CC_FOR_BUILD="$HOST_CC"
else
if test x"$CC" != x; then
CC_FOR_BUILD="$CC"
else
CC_FOR_BUILD=cc
fi
fi
fi
I think this variable should be changed to BUILD_CC not HOST_CC,
that would match the --build --host changes we made to autoconf.
At any rate, I set that variable and it seemed to work ok. We
could always leave an extra check for HOST_CC in for backwards
compatibilty.
setenv HOST_CC gcc
./configure --host=i386-mingw32msvc
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i386-pc-mingw32msvc
checking how to run the C preprocessor... i386-mingw32msvc-gcc -E
checking for i386-mingw32msvc-gcc... i386-mingw32msvc-gcc
checking whether the C compiler works... yes
...
My real question is, why do I need to do this? If autoconf
knows that it is cross compiling then it should know to
set the HOST_CC (or BUILD_CC) to gcc or cc.
Mo DeJong
Red Hat Inc
Re: Cross compile problem.
On 10 Jul 2000, Akim Demaille wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > Mo> I took a peek at the config.guess and found this. > > See http://sources.redhat.com/ml/autoconf/2000-04/msg00097.html and > following :) We should keep a "confusion tally" for sections of the code. The bits that get the most "Huh?" votes get rewritten first :) I am constantly amazed that this stuff works most of the time. I still can't believe there is no way to find the size of a file in a reliable cross platform way (that -g flag detection thing). Mo DeJong Red Hat Inc
Re: aclang.m4 problem (Cygwin + VC++)
On Wed, 12 Jul 2000, Lars J. Aas wrote:
> I've just upgraded our projects to CVS Autoconf and CVS Automake.
> It works great on Unix, but on Cygwin, with the VC++ 6.0 compiler, it
> stops on the "C++ compiler working" test, because it doesn't understand
> that "conftest.cc" is a .cpp file so it defaults to "object file" type
> and fails on "corrupted file". We have to use the filename "conftest.cpp"
> instead. Will such a switch cause any problems on any other platforms?
>
> Lars J
I ran into a problem like the one you describe. It seems
that the CVS version of autoconf does not work with
VC++ at all. When it tries to detect .h files
it fails to find any of them. I was able to trace the
problem down to this bit of code.
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
{ (eval echo configure:1317: \"$ac_try\") >&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
if test -z "$ac_err"; then
:
else
echo "$ac_err" >&5
echo "configure: failed program was:" >&5
cat conftest.$ac_ext >&5
CXXCPP=/lib/cpp
fi
The tests fail for some reason and end up
setting CXXCPP=/lib/cpp. I have a /lib/cpp
file on my linux box, but there is no
such file under Cygwin.
% ls -la /lib/cpp
lrwxrwxrwx1 root root 53 Apr 11 01:36 /lib/cpp ->
../usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/cpp
The result is a bunch of "can not find string.h" type
messages and a config.h that does not work at all.
Mo DeJong
Red Hat Inc
Re: Cross compile problem.
On Wed, 12 Jul 2000, Peter Eisentraut wrote: > Alexandre Oliva writes: > > > > What about systems that don't have a `cc' but only a `gcc' or whatever > > > else? > > > > The user would have to set CC_FOR_BUILD. But see below: > > > > >> In the future, it may be extended to look for gcc if it can't find > > >> cc. > > But that would break things for a lot of people right now. Instead of > writing `CC=/opt/bin/gcc ./configure', they'd have to write > `CC=/opt/bin/gcc CC_FOR_BUILD=/opt/bin/gcc ./configure'? Why should anyone need to set env vars by hand? Here is a quick hack from a configure.in script that I created. What do folks think of this approach? dnl Have the system search for and test out the C compiler AC_PROG_CC dnl This is a hack to work around a bug in autoconf/libtool dnl We need to export CC and CC_FOR_BUILD so that libtool dnl uses the compiler found by ./configure and we can cross. export CC if test "x$cross_compiling" = "xyes" ; then AC_CHECK_PROG(CC_FOR_BUILD, gcc, gcc, cc) export CC_FOR_BUILD fi Mo DeJong Red Hat Inc
No template for symbol error
I am getting this strange error from autoheader. % autoheader autoheader: No template for symbol `PATH_SEPARATOR' The code that defines this var looks like: AC_DEFINE(PATH_SEPARATOR, ';') Whats up with that? If I use the old version of autoheader, it given me some other error. Symbol `PATH_SEPARATOR' is not covered by /usr/share/autoconf/acconfig.h Both of these errors seem wrong, I should be able to call AC_DEFINE with 1, 2, or 3 arguments. Mo DeJong Red Hat Inc
New AC_CANONICAL_BUILD warning and AIX wackyness
I just did a CVS update and I am now getting this warning while running autoconf. ( last updated around 2000-07-06) % ./autogen.sh autoheader: src/config.h.in is unchanged configure.in:23: warning: AC_CANONICAL_BUILD invoked multiple times (line 23) dnl Set up host checks using config.sub and config.guess. AC_CANONICAL_HOST AC_CANONICAL_BUILD Any ideas why autoconf now generates a warning? Also, a user of a package I work on reported the following problem running autoheader from the CVS on and AIX box. Has anyone seen something like this before? ./autogen.sh /opt/autoconf/bin/autoheader: NONE:0:: command not found autoheader: error: AC_CONFIG_HEADERS not found in configure.in NONE:0: /usr/bin/m4: Cannot open /usr/local/share/autoconf/autoconf.m4f: No such file or directory thanks Mo DeJong Red Hat Inc
Re: This configure.in script does not work with autoconf 2.14
On 3 Jul 2000, Akim Demaille wrote: > > | Here is the input from configure.in. > | > | AC_CHECK_FUNC(BSDgettimeofday, AC_DEFINE(HAVE_BSDGETTIMEOFDAY), > | AC_CHECK_FUNC(gettimeofday, , AC_DEFINE(NO_GETTOD))) > | AC_MSG_CHECKING([for gettimeofday declaration]) > | AC_EGREP_HEADER(gettimeofday, sys/time.h, AC_MSG_RESULT(present), [ > | AC_MSG_RESULT(missing) > | AC_DEFINE(GETTOD_NOT_DECLARED) > | ]) > > This is indecent from you Mo, exhibiting all these poor macros naked > on a public list! You could have left their quotes on :) > > AC_CHECK_FUNC(BSDgettimeofday, > [AC_DEFINE(HAVE_BSDGETTIMEOFDAY)], > [AC_CHECK_FUNC(gettimeofday, , > [AC_DEFINE(NO_GETTOD)])]) > > In fact, this might be enough to catch the problem. A common trap > when under quoting is that the (&*£$ syntax of sh) the right parens of > case statements are understood by m4 [1]. I don't know if there are > some above, but in that case the result is a stupid configure. > > I tell you my friend, the path to felicity is paved with quotes :) I took your advice and put a bunch of []s around macros in other macros and that seemed to fix the problem. Only problem is, now I get this warning when I run autoconf. mo(~/project/tcl/unix)% autoconf configure.in:154: warning: AC_STRUCT_ST_BLKSIZE: your code should no longer depend upon `HAVE_ST_BLKSIZE', but `HAVE_STRUCT_STAT_ST_BLKSIZE'. Remove this AC_WARNING and the `AC_DEFINE' when you adjust the code. Here is the bit it seems to be talking about: # # Some systems (e.g., IRIX 4.0.5) lack the st_blksize field # in struct stat. But we might be able to use fstatfs instead. # AC_STRUCT_ST_BLKSIZE AC_CHECK_FUNC(fstatfs, , [AC_DEFINE(NO_FSTATFS)]) I am not sure how to fix this, and ideas? thanks Mo DeJong Red Hat Inc
Re: aclang.m4 problem (Cygwin + VC++)
On 19 Jul 2000, Akim Demaille wrote: > >>>>> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: > > Mo> I ran into a problem like the one you describe. It seems : that > Mo> the CVS version of autoconf does not work with : VC++ at all. > > Lars> This is *bad* news for me, but probably not for Autoconf > Lars> development, as I'll have to work on fixing this... > > Mo, Lars, could you give a look at the patch 25-* and see if it works? Forgive my ignorance, but where would I find "patch 25-*"? Mo DeJong Red Hat Inc
Why does ./configure not set prefix and exec_prefix?
I have run into something that seems really strange to me.
Autoconf will subst @prefix@ and @exec_prefix@ into a
Makefile, but while ./configure is actually running they
are not set. Here is a minimal example.
% cat configure.in
AC_INIT(foo.c)
AC_PROG_CC
echo "prefix is \"$prefix\""
echo "exec_prefix is \"$exec_prefix\""
AC_OUTPUT([Makefile])
% cat Makefile.in
prefix = @prefix@
exec_prefix = @exec_prefix@
Running this produces the following results:
% ./configure
checking for gcc... gcc
...
prefix is "NONE"
exec_prefix is "NONE"
creating ./config.status
creating Makefile
% cat Makefile
prefix = /usr/local
exec_prefix = ${prefix}
Does anyone else find that rather odd? I would like to
be able to set vars that I am going to subst based on
${prefix} and ${exec_prefix}, but it seems that nasty
hacks like the following are required in my configure.in.
if test "${prefix}" = "NONE"; then
prefix=/usr/local
fi
if test "${exec_prefix}" = "NONE"; then
exec_prefix=$prefix
fi
thanks
Mo DeJong
Red Hat Inc
