Re: How to optionally test for a C++ compiler?
* Ossama Othman:
> Something like the following should be a good smoke test:
>
> class Foo
> {
>public:
> Foo (void) : bar_ (0) { }
> virtual ~Foo (void) { }
> virtual int bar (void) { return this->bar_; }
>private:
> int bar_;
> };
>
> int main (int, char *[])
> {
>Foo fnord;
>int a = fnord.bar ();
>return a;
> }
* Olly Betts:
> Just noticed a problem with this. If you compile it with:
>
> gcc -o test test.cc
>
> You get a working executable called test.
The reason for this is that gcc automatically goes into C++ "mode"
when it sees the .cc extension. You need to call gcc with the "-x"
option to explicitly set it to be "C only":
$ gcc -x c -o test test.cc
will yield
test.cc:1: parse error before `Foo'
test.cc:2: syntax error before `{'
test.cc:6: syntax error before `int'
test.cc: In function `bar':
test.cc:6: `this' undeclared (first use in this function)
[snip]
BTW, I second Ossama's arguments for not using a library function. The
C++ test code looks good to me.
Regards,
Morten
vs "config.h"?
Hi, this is probably a silly questions, but I'll take my chance: I was wondering if there's a preferred way to include the config.h file generated by autoconf (with the define settings)? I.e. is there any reason why #include would be better than #include "config.h" (or vice versa) for the "general case"? I couldn't find any mention of this in the docs, and I suspect that if this is an issue, it is a more suitable question to ask within the domain of automake use, as it has possible ramifications for the way $(top_builddir) is used in the include-directories list..? Regards, Morten
Re: Build single library from multiple source directories
Erik de Castro Lopo <[EMAIL PROTECTED]> writes: > Hi all, > > I'm trying to build a single library from multiple source > directories without much luck. Does anybody have any clues > on how this may be done? Maybe a package that does this? We do this for Coin: http://www.coin3d.org>. Regards, Morten
Re: Standard macro for OpenGL check?
"Matthew D. Langston" <[EMAIL PROTECTED]> writes:
> The macro MDL_HAVE_OPENGL is what you want. It is in the Autoconf
> Macro Archive at http://peti.cys.de/autoconf-archive/ in the file
> mdl_have_opengl.m4. It should do everything you want. If it
> doesn't, please let me know (or better yet, send me a patch) as I am
> the original author if it.
Your OpenGL detection macro is seriously flawed in a number of
ways. You should for instance look at the way you use AC_CACHE_CHECK
(hint: there should not be any sideeffects within a cached check).
I started working on fixing the problems of your macro, but I gave up,
the overall structure of the macro is just not flexible enough. So I
wrote my own instead. I've attached it to this mail for your perusal.
Its not perfect, but it seems to work well on the platforms it has
been tested (Linux, HPUX, IRIX, Solaris, BeOS), within the context of
the configure process for the Coin¹ library.
BTW, some major difference from your macro:
* it handles GL and GLU (or Mesa and MesaGLU) exclusively (I've got a
separate macro for GLX)
* it assumes that all the necessary libraries GL depends on has been
configured to be covered by the environment variables LDFLAGS and
LIBS _before_ the macro is run
Regards,
Morten
¹ <http://www.coin3d.org>
dnl Usage:
dnl SIM_CHECK_OPENGL([ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
dnl
dnl Try to find an OpenGL development system, either a native
dnl implementation or the OpenGL-compatible Mesa libraries. If
dnl it is found, these shell variables are set:
dnl
dnl$sim_ac_gl_cppflags (extra flags the compiler needs for OpenGL/Mesa)
dnl$sim_ac_gl_ldflags (extra flags the linker needs for OpenGL/Mesa)
dnl$sim_ac_gl_libs (link libraries the linker needs for OpenGL/Mesa)
dnl
dnl The CPPFLAGS, LDFLAGS and LIBS flags will also be modified accordingly.
dnl In addition, the variable $sim_ac_gl_avail is set to "yes" if an
dnl OpenGL-compatible development system is found. If the OpenGL system
dnl found is the Mesa libraries, we will also set $sim_ac_gl_is_mesa to
dnl "yes".
dnl
dnl
dnl Author: Morten Eriksen, <[EMAIL PROTECTED]>.
dnl
dnl TODO:
dnl* [mortene:2122] make sure this work on MSWin (with
dnl Cygwin installation)
dnl
AC_DEFUN(SIM_CHECK_OPENGL,[
dnl Autoconf is a developer tool, so don't bother to support older versions.
AC_PREREQ([2.14.1])
AC_ARG_WITH(opengl, AC_HELP_STRING([--with-opengl=DIR], [OpenGL/Mesa installation
directory]), , [with_opengl=yes])
sim_ac_gl_avail=no
sim_ac_gl_is_mesa=no
if test x"$with_opengl" != xno; then
if test x"$with_opengl" != xyes; then
sim_ac_gl_cppflags="-I${with_opengl}/include"
sim_ac_gl_ldflags="-L${with_opengl}/lib"
else
case "$host_os" in
hpux*)
# This is a common location for the OpenGL libraries on HPUX.
sim_ac_gl_cppflags="-I/opt/graphics/OpenGL/include"
sim_ac_gl_ldflags="-L/opt/graphics/OpenGL/lib" ;;
esac
fi
sim_ac_save_cppflags=$CPPFLAGS
sim_ac_save_ldflags=$LDFLAGS
CPPFLAGS="$CPPFLAGS $sim_ac_gl_cppflags"
LDFLAGS="$LDFLAGS $sim_ac_gl_ldflags"
sim_ac_save_libs=$LIBS
AC_CACHE_CHECK([whether OpenGL libraries are available], sim_cv_lib_gl, [
sim_cv_lib_gl=UNRESOLVED
# Some platforms (like BeOS) have the GLU functionality in the GL library.
for i in -lMesaGL -lGL "-lMesaGLU -lMesaGL" "-lGLU -lGL"; do
if test "x$sim_cv_lib_gl" = "xUNRESOLVED"; then
LIBS="$i $sim_ac_save_libs"
AC_TRY_LINK([#include
#include ],
[glPointSize(1.0f); gluSphere(0L, 1.0, 1, 1);],
sim_cv_lib_gl="$i")
fi
done
])
if test "x$sim_cv_lib_gl" != "xUNRESOLVED"; then
sim_ac_gl_libs="$sim_cv_lib_gl"
LIBS="$sim_ac_gl_libs $sim_ac_save_libs"
sim_ac_gl_avail=yes
AC_CACHE_CHECK([whether OpenGL libraries are the Mesa libraries],
sim_cv_lib_gl_ismesa,
[AC_TRY_LINK([#include ],
[#ifndef MESA
#error not mesa
#endif],
sim_cv_lib_gl_ismesa=yes,
sim_cv_lib_gl_ismesa=no)])
if test x"$sim_cv_lib_gl_ismesa" = xyes; then
sim_ac_gl_is_mesa=yes
fi
ifelse($1, , :, $1)
else
CPPFLAGS=$sim_ac_save_cppflags
LDFLAGS=$sim_ac_save_ldflags
LIBS=$sim_ac_save_libs
ifelse($2, , :, $2)
fi
fi
])
Re: Standard macro for OpenGL check?
"Braden N. McDaniel" <[EMAIL PROTECTED]> writes: > Suppose I've got a library and I want to install an autoconf macro > on the user's system so that if the user is developing a library > dependent on mine, s/he can use this macro to check for the presence > of my library. [snip] One way to solve the problem you describe can be found in several widely used libraries, like gtk+, glib, the gnome libraries, etc. The solution involves configure building a [libname]-config.sh shell script, containing full information about the other libraries your library depends on (like OpenGL), along with information on paths, etc. By making the autoconf detection macro you provide for checking the presence of your library use this shell config script, you can then "remember" the state of the system when your package was configured. Check out the build system for one of the above mentioned libraries (gtk+, glib, gnome-libs) or the library I'm working on (Coin) for further information. Hope that helps, Morten
Re: Standard macro for OpenGL check?
Akim Demaille <[EMAIL PROTECTED]> writes: > | AC_DEFUN(SIM_CHECK_OPENGL,[ > | dnl Autoconf is a developer tool, so don't bother to support older versions. > | AC_PREREQ([2.14.1]) > > Please, don't depend on this, it does not exist. Guys, get your ass in gear and release a new version of Autoconf, please -- so we don't have to live on the bleeding edge. (Hey, just kidding.) :^} > | case "$host_os" in > > Where does this come from? Hmm, from libtool's ltconfig. Could a host OS identifier be found somewhere by using "standard" Autoconf features? > | ifelse($1, , :, $1) > > Why not just $1? I think I copied the idiom from the Autoconf sources, not really knowing what I did. Lets see.. the same code is at least used in AC_LIST_MEMBER_OF, in my checkout from the CVS head from 2000-01-12. (I probably assumed that the ifelse() construct was needed to handle cases where "$1" = "".) Thanks for your comments, they are really appreciated. Regards, Morten
Re: Standard macro for OpenGL check?
"Braden N. McDaniel" <[EMAIL PROTECTED]> writes: > Might there be any interest in having a standard macro to check for > OpenGL packaged with autoconf? There's already such a thing for X; > so I wonder, how about OpenGL? Sounds like a good idea to me, as OpenGL is getting to be a pretty common library these days with good coverage of the various platforms out there. One interesting tidbit, BTW: OpenGL is now a standard part of XFree86, from release 4.0 (which was released just yesterday) and onwards. > If there's interest in this, I have a macro that might serve as a > starting point. Though I've hacked on it a bit, I am not its > progenitor and I'm afraid I don't know who that is. I've got an OpenGL detection macro written from scratch by myself which seems to hold up pretty good. It has been tested and found to work on various Linux platforms, FreeBSD, Solaris, IRIX, HP-UX and BeOS, at least. Feel free to check it out, its part of the source distribution of the Coin library: http://www.coin3d.org>. I believe it could be a decent starting point for a macro to migrate into the standard Autoconf distribution, if the maintainers feels this is a good idea. Regards, Morten
[PATCH] miniscule documentation fix
An example from the AC_HELP_STRING doc was missing a parenthesis. Regards, Morten Eriksen Index: autoconf.texi === RCS file: /cvs/autoconf/doc/autoconf.texi,v retrieving revision 1.247 diff -u -r1.247 autoconf.texi --- autoconf.texi 2000/03/20 10:10:06 1.247 +++ autoconf.texi 2000/04/02 17:54:59 @@ -5559,7 +5559,7 @@ @example AC_DEFUN(TEST_MACRO, [AC_ARG_WITH(foo, - AC_HELP_STRING([--with-foo], [use foo (default is NO)], + AC_HELP_STRING([--with-foo], [use foo (default is NO)]), ac_cv_use_foo=$withval, ac_cv_use_foo=no), AC_CACHE_CHECK(whether to use foo, ac_cv_use_foo, ac_cv_use_foo=no)]) @end example
[PATCH] X11 linking
I forgot to CC: this mail to the [EMAIL PROTECTED] list.
Regards,
Morten
Hi,
I was chasing a problem where configure-scripts under IRIX 6.5 with
the SGI Mipspro v7.30 C++ compiler refused to link against X11 unless
the user applied some magic by setting environment variables etc.
I believe I found the root of the problem within _AC_PATH_X_DIRECT,
where the first X11 linkcheck fails due to a missing
#include-statement in the testcode. (Rather amazing that this nasty
bug has survived for so long -- it has at least been present for > 6
months, probably even longer.)
Patch against current CVS head branch attached below. (Note: the patch
hasn't been tested, as I'm running an older Autoconf at the moment,
due to the mismatch with the current CVS Automake.)
Mon May 29 15:35:51 2000 Morten Eriksen <[EMAIL PROTECTED]>
* acspecific.m4: Fix the first X11 linktest in
_AC_PATH_X_DIRECT to actually have a chance of
succeeding. Also killed an unnecessary shell variable.
Index: acspecific.m4
===
RCS file: /cvs/autoconf/acspecific.m4,v
retrieving revision 1.272
diff -u -r1.272 acspecific.m4
--- acspecific.m4 2000/05/28 16:27:56 1.272
+++ acspecific.m4 2000/05/29 13:32:25
@@ -2379,13 +2379,12 @@
# Check for the libraries.
test -z "$ac_x_direct_test_library" && ac_x_direct_test_library=Xt
- test -z "$ac_x_direct_test_function" && ac_x_direct_test_function=XtMalloc
# See if we find them without any special options.
# Don't add to $LIBS permanently.
ac_save_LIBS=$LIBS
LIBS="-l$ac_x_direct_test_library $LIBS"
-AC_TRY_LINK(, [${ac_x_direct_test_function}()],
+AC_TRY_LINK([#include <$ac_x_direct_test_include>], [(void)XtMalloc(0)],
[LIBS=$ac_save_LIBS
# We can link X programs with no special library path.
ac_x_libraries=],
Regards,
Morten Eriksen
Re: configure.in in subdirectories
Diego Sevilla Ruiz <[EMAIL PROTECTED]> writes: > [...] AC_CONFIG_SUBDIRS [...] does automake support this macro and > descend to the subdirectories to build Makefile.in, etc? No. > (and autoconf for generating its corresonding subdir/configure? No. > or must I do it myself? Yes. If you know you want to regenerate all the Makefile.in, configure etc files each time you do it on the root directory, I guess you could just add a call to the "bootstrapping" scripts in the subdirectories from your root bootstrapping script. So it's no big deal to set up manually. Regards, Morten
Re: AC_CHECK_LIB and C++
Bram Stolk <[EMAIL PROTECTED]> writes: > I want to check for simple global C++ func. However, even if I set > the language to C++, the conftest.C is created in such a way, that > the func I am looking for is prototyped in "extern C", thereby > causing the check to fail. You're probably running into one or both of these problems: * the function name in the library is mangled * the C++ compiler and/or linker doesn't like trying to link your function against the default "int func(void)" signature that AC_CHECK_LIB tries to do (I know this happens with SGI MIPSpro v7.30 at least) In short, the AC_CHECK_LIB macro doesn't really work with C++ libraries, and might not even work with C libraries if the current language has been set to C++. The simple workaround is to replace your use of AC_CHECK_LIB with AC_TRY_LINK, where you supply a code snippet that tries to use some functionality of the library _properly_. Regards, Morten
Bugfix for _AC_OBJEXT
Hi, this fixes a bug when running configure scripts with compilers which generates object-files where the suffix is not the default ".o": _AC_OBJEXT uses AC_COMPILE_IFELSE, but AC_COMPILE_IFELSE contains this snippet of code [...] if AC_TRY_EVAL(ac_compile) && test -s conftest.$ac_objext; then [...] I.e., the AC_COMPILE_IFELSE macro depends on the value of $ac_objext (which defaults to .o before _AC_OBJEXT is called). This means compilers using .obj or .xcoff, for instance, will fail the "test -s" case, which makes AC_COMPILE_IFELSE fail, which in turn makes _AC_OBJEXT abort the configure script with an AC_MSG_ERROR. BTW, looking some more at the code, this looks like a hornet's nest of bugs. IMO, $ac_objext shouldn't have a default value at all, and AC_COMPILE_IFELSE should AC_REQUIRE the _AC_OBJEXT macro -- since the value of $ac_objext will not be correct until _AC_OBJEXT is called anyhow for compilers not using the .o suffix for object files. But this will in turn lead to other "dependency deadlock" problems, since AC_COMPILE_IFELSE is used to detect a working compiler, and a working compiler is needed by _AC_OBJEXT to detect the object extension suffix. In addition, it also seems to me (after a quick glance) that _AC_EXEEXT have some of the same problems; it calls AC_LINK_IFELSE, but AC_LINK_IFELSE depends on the value of $ac_exeext being correct. There's an ugly workaround for this in the _AC_EXEEXT macro -- the value of $ac_exeext is explicitly set to .exe if CYGWIN, MINGW32 or EMXOS2 is detected. As I said, a hornet's nest. Was anyone on the list aware of these bugs? Regards, Morten ========= 2000-08-30 Morten Eriksen <[EMAIL PROTECTED]> * acspecific.m4: _AC_OBJEXT was using AC_COMPILE_IFELSE, but AC_COMPILE_IFELSE depends on the value of $ac_objext. This dependency deadlock is broken by making _AC_OBJEXT independent of AC_COMPILE_IFELSE. Index: acspecific.m4 === RCS file: /cvs/autoconf/acspecific.m4,v retrieving revision 1.293 diff -u -r1.293 acspecific.m4 --- acspecific.m4 2000/08/04 09:21:52 1.293 +++ acspecific.m4 2000/08/30 14:05:10 @@ -1586,16 +1586,22 @@ # determined by ac_objext. define([_AC_OBJEXT], [AC_CACHE_CHECK([for object suffix], ac_cv_objext, -[AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], - [for ac_file in conftest.*; do -case $ac_file in - *.$ac_ext) ;; - *) ac_cv_objext=`echo $ac_file | sed s/conftest.//` ;; -esac - done], - [AC_MSG_ERROR([cannot compile])])]) +[AC_LANG_CONFTEST([AC_LANG_PROGRAM()]) + if AC_TRY_EVAL(ac_compile); then + for ac_file in conftest.*; do + case $ac_file in + *.$ac_ext) ;; + *) ac_cv_objext=`echo $ac_file | sed s/conftest.//` ;; + esac + done + else + rm -f conftest.$ac_ext + AC_MSG_ERROR([cannot compile]) + fi +]) AC_SUBST(OBJEXT, $ac_cv_objext)dnl ac_objext=$ac_cv_objext +rm -f conftest.$ac_objext conftest.$ac_ext ])# _AC_OBJEXT
Re: C++ Shared Libraries
Robert Boehne <[EMAIL PROTECTED]> writes: > From what I have read about libtool it cannot handle C++ shared > libs. [...] Well, it works for us (http://www.coin3d.org) with a number of large and complex C++ libraries. (We're using Libtool v1.3.5, BTW.) > Is there any work going on in this area, [...] Yes, there's a separate libtool CVS-branch which have improvements to the C++-support. Regards, Morten
Re: Bugfix for _AC_OBJEXT
Akim Demaille <[EMAIL PROTECTED]> writes: > Meanwhile, I OK your patch. Thanks. I've got an updated version attached below, with the only additions that AC_OBJEXT is called before AC_EXEEXT in AC_PROG_CC, AC_PROG_CXX and AC_PROG_F77 (AC_EXEEXT uses $ac_objext). > I'd accept patches that do what you suggest too: have _AC_EXEEXT be > independent from AC_LINK_IFELSE, have AC_LINK|COMPILE_IFELSE require > what they need, [...] I looked at the code, but the macros that does the various compiler checks doesn't look "ready" for this change -- in particular, it looks hard to do the necessary changes without breaking the newly introduced AC_NO_EXECUTABLES hack. So I'm afraid I'll leave that mess alone for now. :^/ Regards, Morten 2000-08-30 Morten Eriksen <[EMAIL PROTECTED]> * acspecific.m4: _AC_OBJEXT was using AC_COMPILE_IFELSE, but AC_COMPILE_IFELSE depends on the value of $ac_objext. This dependency deadlock is broken by making _AC_OBJEXT independent of AC_COMPILE_IFELSE. * aclang.m4: _AC_EXEEXT depends on the value of $ac_objext, so run _AC_OBJEXT before _AC_EXEEXT. Also fixes a miniscule typo. ? all.diff Index: aclang.m4 === RCS file: /cvs/autoconf/aclang.m4,v retrieving revision 1.59 diff -u -r1.59 aclang.m4 --- aclang.m4 2000/09/05 09:14:10 1.59 +++ aclang.m4 2000/09/06 10:13:07 @@ -238,7 +238,7 @@ # AC_LANG_CONFTEST(BODY) # - -# Save the BODY in `conftest.$acext'. Add a trailing new line. +# Save the BODY in `conftest.$ac_ext'. Add a trailing new line. define([AC_LANG_CONFTEST], [cat >conftest.$ac_ext <<_ACEOF $1 @@ -610,8 +610,8 @@ _AC_LANG_COMPILER_WORKS _AC_PROG_CC_GNU _AC_PROG_CC_G -AC_EXPAND_ONCE([_AC_EXEEXT]) AC_EXPAND_ONCE([_AC_OBJEXT]) +AC_EXPAND_ONCE([_AC_EXEEXT]) AC_LANG_POP ])# AC_PROG_CC @@ -802,8 +802,8 @@ _AC_LANG_COMPILER_WORKS _AC_PROG_CXX_GNU _AC_PROG_CXX_G -AC_EXPAND_ONCE([_AC_EXEEXT]) AC_EXPAND_ONCE([_AC_OBJEXT]) +AC_EXPAND_ONCE([_AC_EXEEXT]) AC_LANG_POP ])# AC_PROG_CXX @@ -901,9 +901,8 @@ _AC_LANG_COMPILER_WORKS _AC_PROG_F77_GNU _AC_PROG_F77_G - -AC_EXPAND_ONCE([_AC_EXEEXT]) AC_EXPAND_ONCE([_AC_OBJEXT]) +AC_EXPAND_ONCE([_AC_EXEEXT]) AC_LANG_POP ])# AC_PROG_F77 Index: acspecific.m4 === RCS file: /cvs/autoconf/acspecific.m4,v retrieving revision 1.293 diff -u -r1.293 acspecific.m4 --- acspecific.m4 2000/08/04 09:21:52 1.293 +++ acspecific.m4 2000/09/06 10:13:08 @@ -1586,16 +1586,22 @@ # determined by ac_objext. define([_AC_OBJEXT], [AC_CACHE_CHECK([for object suffix], ac_cv_objext, -[AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], - [for ac_file in conftest.*; do -case $ac_file in - *.$ac_ext) ;; - *) ac_cv_objext=`echo $ac_file | sed s/conftest.//` ;; -esac - done], - [AC_MSG_ERROR([cannot compile])])]) +[AC_LANG_CONFTEST([AC_LANG_PROGRAM()]) + if AC_TRY_EVAL(ac_compile); then + for ac_file in conftest.*; do + case $ac_file in + *.$ac_ext) ;; + *) ac_cv_objext=`echo $ac_file | sed s/conftest.//` ;; + esac + done + else + rm -f conftest.$ac_ext + AC_MSG_ERROR([cannot compile]) + fi +]) AC_SUBST(OBJEXT, $ac_cv_objext)dnl ac_objext=$ac_cv_objext +rm -f conftest.$ac_objext conftest.$ac_ext ])# _AC_OBJEXT
Re: Bugfix for _AC_OBJEXT
"Lars J. Aas" <[EMAIL PROTECTED]> writes: > Actually, it doesn't. Many of the initial configure tests fail on > Cygwin because of this mess, I seem to recall. None of the important ones, I believe (my patch fixes the only case I could find). There are some ugly hacks in Autoconf to take special care of Cygwin, Mingw and OS/2 platforms, though -- which should eventually be removed along with the general cleanup with regard to _AC_OBJEXT, _AC_EXEEXT and related macros. But I agree with Akim that it works well enough (_just_) to release v2.50. Morten
Should the C++ sourcefile extension be changed?
Hi,
I see there was a suggestion to change the extension for C++
sourcecode files a couple of months ago. Someone had tested the .cxx
extension and found it to work with all compilers he could lay his
hands on (quite a few on UNIX systems, plus at least MSVisualC++ on
MSWindows).
So, as the current extension (.cc) _really_ confuses MSVisualC++, it'd
be nice if the patch below is applied before releasing v2.50.
Regards,
Morten
Index: ChangeLog
===
RCS file: /cvs/autoconf/ChangeLog,v
retrieving revision 1.854
diff -u -r1.854 ChangeLog
--- ChangeLog 2000/09/12 10:23:08 1.854
+++ ChangeLog 2000/09/12 11:05:50
@@ -1,3 +1,9 @@
+2000-09-12 Morten Eriksen <[EMAIL PROTECTED]>
+
+ * aclang.m4 (AC_LANG(C++)): Use .cxx instead of .cc as
+ extension for C++, to please more compilers (MSVisualC++
+ does not like files named with .cc, for instance).
+
2000-09-12 Pavel Roskin <[EMAIL PROTECTED]>
* acgeneral.m4 (AC_EGREP_CPP): Use additional quotes instead of
Index: aclang.m4
===
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.60
diff -u -r1.60 aclang.m4
--- aclang.m4 2000/09/06 13:05:58 1.60
+++ aclang.m4 2000/09/12 11:05:51
@@ -188,7 +188,7 @@
#
# CXXFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options.
define([AC_LANG(C++)],
-[ac_ext=cc
+[ac_ext=cxx
ac_cpp='$CXXCPP $CPPFLAGS'
ac_compile='${CXX-g++} -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&AC_FD_LOG'
ac_link='${CXX-g++} -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS >&AC_FD_LOG'
Serious problem with Autoconf on RedHat 7
Hi,
I just discovered a nasty problem with the latest CVS Autoconf on Red
Hat Linux v7 (default setup, i.e. with g++ 2.96). In short, the
AC_TRY_COMPILE in the configure.in script below will fail:
->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--
AC_INIT(configure.in)
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include ], [], , AC_MSG_ERROR(sorr-ee))
AC_OUTPUT()
->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--
Here's the relevant part of config.log:
->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--
[...]
configure:1141: g++ -c -g -O2 conftest.cpp >&5
In file included from configure:1135:
/usr/include/stdlib.h:578: declaration of `void exit (int) throw ()'
throws different exceptions
configure:1132: than previous declaration `void exit (int)'
configure: failed program was:
#line 1130 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit (int);
#endif
#include
int
main ()
{
;
return 0;
}
->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--
Now, this is obviously due to the "extern" forward declaration of
exit() not matching the exit() defined by the stdlib.h of GCC 2.96
when run as a C++ compiler.
Why is the explicit exit() declaration there anyway? Removing it will
of course make the configure script run correctly.
Regards,
Morten
[PATCH] Serious problem with Autoconf on RedHat 7
Hi,
I don't know if this mail got through without losing a few electrons
due to the recent mailinglist hickups, so I'm resending it. With a
patch this time, so it might be easier to get it applied. :^}
2000-10-02 Morten Eriksen <[EMAIL PROTECTED]>
* aclang.m4 (AC_LANG_SOURCE(C++)): don't define exit(), it'll
mismatch with the native exit() definition on some platforms
(happens at least with g++ 2.96 and glibc 2.1.92 on Red Hat Linux
v7).
Regards,
Morten
Index: ChangeLog
===
RCS file: /cvs/autoconf/ChangeLog,v
retrieving revision 1.895
diff -u -r1.895 ChangeLog
--- ChangeLog 2000/10/02 13:11:27 1.895
+++ ChangeLog 2000/10/02 17:24:17
@@ -1,3 +1,10 @@
+2000-10-02 Morten Eriksen <[EMAIL PROTECTED]>
+
+ * aclang.m4 (AC_LANG_SOURCE(C++)): don't define exit(), it'll
+ mismatch with the native exit() definition on some platforms
+ (happens at least with g++ 2.96 and glibc 2.1.92 on Red Hat Linux
+ v7).
+
2000-10-02 Akim Demaille <[EMAIL PROTECTED]>
* aclang.m4 (_AC_LANG_ABBREV, _AC_LANG_ABBREV(C))
Index: aclang.m4
===
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.68
diff -u -r1.68 aclang.m4
--- aclang.m4 2000/10/02 13:11:28 1.68
+++ aclang.m4 2000/10/02 17:19:28
@@ -412,9 +412,6 @@
define([AC_LANG_SOURCE(C++)],
[#line __oline__ "configure"
#include "confdefs.h"
-#ifdef __cplusplus
-extern "C" void exit (int);
-#endif
$1])
Hi,
I just discovered a nasty problem with the latest CVS Autoconf on Red
Hat Linux v7 (default setup, i.e. with g++ 2.96). In short, the
AC_TRY_COMPILE in the configure.in script below will fail:
->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--
AC_INIT(configure.in)
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include ], [], , AC_MSG_ERROR(sorr-ee))
AC_OUTPUT()
->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--
Here's the relevant part of config.log:
->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--
[...]
configure:1141: g++ -c -g -O2 conftest.cpp >&5
In file included from configure:1135:
/usr/include/stdlib.h:578: declaration of `void exit (int) throw ()'
throws different exceptions
configure:1132: than previous declaration `void exit (int)'
configure: failed program was:
#line 1130 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit (int);
#endif
#include
int
main ()
{
;
return 0;
}
->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--->8-->8--
Now, this is obviously due to the "extern" forward declaration of
exit() not matching the exit() defined by the stdlib.h of GCC 2.96
when run as a C++ compiler.
Why is the explicit exit() declaration there anyway? Removing it will
of course make the configure script run correctly.
Regards,
Morten
Re: [PATCH] Serious problem with Autoconf on RedHat 7
Akim Demaille <[EMAIL PROTECTED]> writes: > | Index: aclang.m4 > | === > | RCS file: /cvs/autoconf/aclang.m4,v > | retrieving revision 1.68 > | diff -u -r1.68 aclang.m4 > | --- aclang.m4 2000/10/02 13:11:28 1.68 > | +++ aclang.m4 2000/10/02 17:19:28 > | @@ -412,9 +412,6 @@ > | define([AC_LANG_SOURCE(C++)], > | [#line __oline__ "configure" > | #include "confdefs.h" > | -#ifdef __cplusplus > | -extern "C" void exit (int); > | -#endif > | $1]) > > I'm in favor of this patch given that it applies only to C++. Note > however, that it does not solve the problem for people who use > CC=g++. Are you sure there _is_ a problem when using CC=g++? I'm at least not seeing any with this configure.in: AC_INIT(configure.in) AC_LANG_C AC_TRY_COMPILE([#include ], [], , AC_MSG_ERROR(sorr-ee)) AC_OUTPUT() ..and configure run like this: $ ./configure CC=g++ Which shouldn't be any surprise, as AC_LANG_SOURCE(C) does not add any explicit exit() declaration, like AC_LANG_SOURCE(C++) does. It'd be interesting to know what the ``extern "C" void exit (int);'' was doing there in the first place..? BTW, the ``#ifdef __cplusplus'' also looks strange, given that the macro name AC_LANG_SOURCE(C++) seems to assert that we are always using a C++ compiler to compile the generated source file? Regards, Morten
AC_PROG_CC not working
Hi, I don't see the expected behavior from the AC_PROG_CC macro. This configure.in file: -->8>8>8>8>8>8>8>8>8-- AC_INIT(configure.in) AC_PROG_CC(foo bar supercompiler) AC_OUTPUT() -->8>8>8>8>8>8>8>8>8-- ..will generate this output: -->8>8>8>8>8>8>8>8>8-- checking for gcc... gcc checking whether the C compiler works... yes checking whether we are cross compiling... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for object suffix... o checking for Cygwin environment... no checking for mingw32 environment... no checking for EMX OS/2 environment... no checking for executable suffix... checking for foo... (cached) gcc checking whether the C compiler works... yes checking whether we are cross compiling... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes creating ./config.status -->8>8>8>8>8>8>8>8>8-- (This is with the latest Autoconf sources from the head CVS branch.) The obvious reason for this behavior is that AC_PROG_CC requires AC_PROG_CPP to run before the AC_PROG_CC macro body. This will then pick up the gcc compiler (if present) and then use the cached value for CC, no matter which compilers we specify for AC_PROG_CC. Any suggestions on how to solve this? Regards, Morten
Re: AC_PROG_CC not working
Akim Demaille <[EMAIL PROTECTED]> writes: > Really, giving a list of compilers seems bad to me. It should be > the same list for everybody, i.e., let's fix the Autoconf builtin > list if its wrong, but let's not go for various flavors of > configure. A few days ago I would have agreed with you on this point -- but now I'm not so sure anymore. The particular challenge I just bumped into is how to let Autoconf configure know about a "self-made compiler", in the sense that I have written a wrapper script around the MSVC++ cl.exe compiler (to let it behave properly when run from the makefiles generated by Automake). This wrapper is a shell script residing in some source directory of my package, and may be viewed as a separate compiler existing only for this project. Adding the name of my wrapper script to the beginning of the standard list of compilers and calling AC_PROG_CC with this as an argument seemed like the perfect way to integrate the script. But alas, that was not to be, due to the buggy nature of this feature of AC_PROG_CC. So, if fixing the AC_PROG_CC bug is pointless because you think it is wrong policy for AC_PROG_CC to take this argument, I see 2 other options for my task at hand: 1) notify in the INSTALL file about needing to pass on CC=[path/wrapperscript] when building with MSVC++. Simple enough, but it doesn't seem like good policy to me to "push complexity" on to the user. 2) lobby to get my MSVC++ cl.exe wrapper script shipped as a standard part of either the Autoconf or the Automake distribution (and add the name of it to the list of compilers AC_PROG_CC looks for). Eventually I hope to go for option 2), but this doesn't seem like something which would go into the next version of Autoconf or Automake, at least (it need to be properly tested, robustified, etc etc). And I need it _now_, of course. Regards, Morten
Re: AC_PROG_CC not working
Akim Demaille <[EMAIL PROTECTED]> writes: > So I am back to something I raised some time ago: why the heck do we > have to compile to recognize Mingw etc.? Can't we just uname? I'll second that notion. :^) One argument for using the output of uname in some form instead of the current scheme is that the Cygwin test (at least) will fail if not using GCC as the compiler. I'm using MSVC++ cl.exe now, and the Cygwin check gives me a false negative because it's checking for the current compiler to define __CYGWIN__. (BTW, isn't it bad style of Autoconf to need to check for Cygwin, Mingw and EMX OS/2 in the first place? I can see the result is used in the AC_EXEEXT check -- but this macro is fubar anyhow and in bad need of a rewrite.) Regards, Morten
[PATCH] A better (?) _AC_EXEEXT
Hi, this issue was touched upon earlier today: how the _AC_EXEEXT macro does host-checking for Cygwin|Mingw|EMXOS2 when deciding the value of $ac_exeext (which seems like an ugly mismatch with standard Autoconf policy of checking for _features_ to me). It was also mentioned on the list a while ago (by yours truly) how the _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT. My new version of the _AC_EXEEXT macro fixes both these problems, with a change in behavior: it now just searches (in a prefered order) for a valid executable suffix -- instead of trying hard to find _the_ correct suffix. BTW, is the "-ef" option to ``test'' portable? If not, that part could be stripped out. AFAICS, this should also kill the last trace of use of _AC_CYGWIN, _AC_MINGW32 and _AC_EMXOS2. Regards, Morten Index: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.897 diff -u -r1.897 ChangeLog --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/10 16:29:34 @@ -1,3 +1,9 @@ +2000-10-10 Morten Eriksen <[EMAIL PROTECTED]> + + * acspecific.m4 (_AC_EXEEXT): Change of strategy for the macro, we + now search for a valid executable suffix. The old code had circular + dependencies which basically made it fubar. + 2000-10-05 Akim Demaille <[EMAIL PROTECTED]> Check that updated scripts are valid scripts. Index: acspecific.m4 === RCS file: /cvs/autoconf/acspecific.m4,v retrieving revision 1.300 diff -u -r1.300 acspecific.m4 --- acspecific.m4 2000/10/02 12:47:13 1.300 +++ acspecific.m4 2000/10/10 16:29:36 @@ -1554,35 +1552,31 @@ # _AC_EXEEXT # -- -# Check for the extension used for executables. This knows that we -# add .exe for Cygwin or mingw32. Otherwise, it compiles a test -# executable. If this is called, the executable extensions will be -# automatically used by link commands run by the configure script. +# Check for a valid extension to use for executables. define([_AC_EXEEXT], -[_AC_CYGWIN -_AC_MINGW32 -_AC_EMXOS2 -AC_CACHE_CHECK([for executable suffix], ac_cv_exeext, -[case "$CYGWIN $MINGW32 $EMXOS2" in - *yes*) ac_cv_exeext=.exe ;; - *) - AC_LINK_IFELSE([AC_LANG_PROGRAM()], - [if test ! -f conftest; then -for ac_file in conftest.*; do - case $ac_file in - *.$ac_ext | *.o | *.obj | *.xcoff) ;; - *) ac_cv_exeext=`expr "$ac_file" : 'conftest\(.*\)'`;; - esac - done - fi], - [AC_MSG_ERROR([cannot compile and link])]) - test -n "$ac_cv_exeext" && ac_cv_exeext=no;; -esac]) -EXEEXT= -test "$ac_cv_exeext" != no && EXEEXT=$ac_cv_exeext -dnl Setting ac_exeext will implicitly change the ac_link command. -ac_exeext=$EXEEXT -AC_SUBST(EXEEXT)dnl +[AC_CACHE_CHECK([for executable suffix], ac_cv_exeext, +[# Try to compile and link an executable with no suffix first. +ac_exeext= +AC_LINK_IFELSE([AC_LANG_PROGRAM], + [# Ok, we can use an empty suffix for executables. Now see if the + # executable with the empty suffix is just a filesystem mapping + # from the real file (this happens under Cygwin, for instance). + if test conftest -ef conftest.exe; then +# Prefer .exe over empty suffix. +ac_cv_exeext=.exe + else +ac_cv_exeext= + fi + ], + [# Couldn't use empty suffix, try with suffix commonly used + # on MSWindows platforms. + ac_exeext=.exe + AC_LINK_IFELSE([AC_LANG_PROGRAM], [ac_cv_exeext=.exe], + [AC_MSG_ERROR(cannot compile and link)]) + ]) +]) +EXEEXT=$ac_cv_exeext +AC_SUBST(EXEEXT) ])# _AC_EXEEXT
Re: [PATCH] A better (?) _AC_EXEEXT
* Morten
| It was also mentioned on the list a while ago (by yours truly) how the
| _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses
| AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT.
* Akim
| AFAICS you still have this problem: you use AC_LINK_IFELSE. You
| shouldn't, rather, see how AC_OBJEXT uses AC_TRY_EVAL directly,
| that's the way to go.
Nope -- and I should know, as I'm the one who rewrote AC_OBJEXT to use
AC_TRY_EVAL. :^)
Anyway, that's exactly what I was trying to do with AC_EXEEXT too,
until I stumbled into this: to find the suffix for an executable, we
need to compile a sourcecode file into an executable, but to make an
executable we need to know which name to give it.
Or to put it like this: what do you end up with if you use
AC_TRY_EVAL(ac_link)? Here's the definition of ac_link for C:
${CC-cc} -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS
>&AC_FD_LOG
See that "conftest$ac_exeext"? :^/ Ok, no problem I thought -- I'd
just eval this instead:
${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&AC_FD_LOG
..but this would of course give us an executable named "a.out" with
just about every UNIX compiler under the sun. And I don't think ".out"
is the suffix we want to use on UNIX platforms..
So I actually think its pretty hard to find the "default executable
suffix" on a platform without playing nasty tricks. That's why I've
changed the semantics of _AC_EXEEXT to rather check for a valid suffix
among an ordered list of prefered suffices we'd like to use.
* Akim
| The previous code was, apparently, able to cope with other
| extensions than `' and `.exe'.
The previous code was completely fubar and a butt-ugly joke. There's
no chance in hell it would have coped with any platform where the
executable suffix was anything but blank. Oh, and it could cope with
.exe on exactly three specific platforms -- through the hack of naming
those three platforms explicitly.
| I know of no others, agreed, but we could keep this part. I
| wouldn't struggle though :)
The new _AC_EXEEXT could easily be extended to try out any other
executable suffix, if any platform was discovered where it would serve
a purpose.
* Morten
| BTW, is the "-ef" option to ``test'' portable? If not, that part could
| be stripped out.
* Akim
| [no]
Ok, I'll rewrite that part then, and re-submit with a new patch
tomorrow.
* Morten
| AFAICS, this should also kill the last trace of use of _AC_CYGWIN,
| _AC_MINGW32 and _AC_EMXOS2.
* Akim
| This is good and bad. I'm in favor of removing these macros,
| because people should then depend upon AC_CANONICAL_HOST. But if
| some people think we should keep them, then we should reimplement
| then on top of the AC_CANONICAL macros.
I've already rewritten _AC_CYGWIN to use AC_CANONICAL_something (where
"something"="TARGET", I think). It was kinda hard to figure out the
correct semantics of the macros, though -- what AC_CANONICAL_x should
be used?
I'll submit a patch for this too. I assume those macros should be
marked "obsolete" aswell? I haven't really looked at the Autoconf
mechanisms to do this, so I might need a helping hand to complete the
patch.
Regards,
Morten
[PATCH] A better _AC_EXEEXT, Take II
This new version of the patch avoids the non-portable use of the "-ef" option to ``test''. Is this one ok? Regards, Morten Index: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.897 diff -u -r1.897 ChangeLog --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/11 09:28:11 @@ -1,3 +1,9 @@ +2000-10-10 Morten Eriksen <[EMAIL PROTECTED]> + + * acspecific.m4 (_AC_EXEEXT): Change of strategy for the macro, we + now search for a valid executable suffix. The old code had circular + dependencies which basically made it fubar. + 2000-10-05 Akim Demaille <[EMAIL PROTECTED]> Check that updated scripts are valid scripts. Index: acspecific.m4 === RCS file: /cvs/autoconf/acspecific.m4,v retrieving revision 1.300 diff -u -r1.300 acspecific.m4 --- acspecific.m4 2000/10/02 12:47:13 1.300 +++ acspecific.m4 2000/10/11 09:28:12 @@ -1554,35 +1551,33 @@ # _AC_EXEEXT # -- -# Check for the extension used for executables. This knows that we -# add .exe for Cygwin or mingw32. Otherwise, it compiles a test -# executable. If this is called, the executable extensions will be -# automatically used by link commands run by the configure script. +# Check for a valid extension to use for executables. define([_AC_EXEEXT], -[_AC_CYGWIN -_AC_MINGW32 -_AC_EMXOS2 -AC_CACHE_CHECK([for executable suffix], ac_cv_exeext, -[case "$CYGWIN $MINGW32 $EMXOS2" in - *yes*) ac_cv_exeext=.exe ;; - *) - AC_LINK_IFELSE([AC_LANG_PROGRAM()], - [if test ! -f conftest; then -for ac_file in conftest.*; do - case $ac_file in - *.$ac_ext | *.o | *.obj | *.xcoff) ;; - *) ac_cv_exeext=`expr "$ac_file" : 'conftest\(.*\)'`;; - esac - done - fi], - [AC_MSG_ERROR([cannot compile and link])]) - test -n "$ac_cv_exeext" && ac_cv_exeext=no;; -esac]) -EXEEXT= -test "$ac_cv_exeext" != no && EXEEXT=$ac_cv_exeext -dnl Setting ac_exeext will implicitly change the ac_link command. -ac_exeext=$EXEEXT -AC_SUBST(EXEEXT)dnl +[AC_CACHE_CHECK([for executable suffix], ac_cv_exeext, +[# Try to compile and link an executable with no suffix first. +ac_exeext= +AC_LINK_IFELSE([AC_LANG_PROGRAM], + [ac_cv_exeext= + # Ok, we can use an empty suffix for executables. Now see if the + # executable with the empty suffix is just a filesystem mapping + # from the real file (this happens under Cygwin, for instance). + if test -f conftest.exe; then +if test "`ls -i conftest.exe | sed s%[[^0-9]].*$%%`" = \ +"`ls -i conftest | sed s%[[^0-9]].*$%%`"; then + # Prefer .exe over empty suffix. + ac_cv_exeext=.exe +fi + fi + ], + [# Couldn't use empty suffix, try with suffix commonly used + # on MSWindows platforms. + ac_exeext=.exe + AC_LINK_IFELSE([AC_LANG_PROGRAM], [ac_cv_exeext=.exe], + [AC_MSG_ERROR(cannot compile and link)]) + ]) +]) +EXEEXT=$ac_cv_exeext +AC_SUBST(EXEEXT) ])# _AC_EXEEXT
[PATCH] Misc fixes for use of extension suffices
Hi,
this patch contains various simple fixes for misuse or missing use of
the object file extension and executable file suffix.
Regards,
Morten
Index: ChangeLog
===
RCS file: /cvs/autoconf/ChangeLog,v
retrieving revision 1.897
diff -u -r1.897 ChangeLog
--- ChangeLog 2000/10/05 13:52:41 1.897
+++ ChangeLog 2000/10/11 10:05:54
@@ -1,3 +1,10 @@
+2000-10-11 Morten Eriksen <[EMAIL PROTECTED]>
+
+ * acgeneral.m4 (AC_RUN_IFELSE): Add missing executable suffix.
+ * aclang.m4 (_AC_LANG_COMPILER_WORKS): Likewise.
+ * aclang.m4 (AC_PROG_CC_C_O, AC_PROG_F77_C_O): Fix typos where
+ $objext were used instead of $ac_objext.
+
2000-10-05 Akim Demaille <[EMAIL PROTECTED]>
Check that updated scripts are valid scripts.
Index: acgeneral.m4
===
RCS file: /cvs/autoconf/acgeneral.m4,v
retrieving revision 1.563
diff -u -r1.563 acgeneral.m4
--- acgeneral.m42000/10/02 13:11:28 1.563
+++ acgeneral.m42000/10/11 10:00:24
@@ -3455,7 +3455,7 @@
[AC_LANG_COMPILER_REQUIRE()dnl
m4_ifvanl([$1], [AC_LANG_CONFTEST([$1])])dnl
if AC_TRY_EVAL(ac_link) &&
- test -s conftest$ac_exeext && (./conftest; exit) 2>/dev/null; then
+ test -s conftest$ac_exeext && (./conftest$ac_exeext; exit) 2>/dev/null; then
m4_default([$2], :)
else
echo "configure: failed program was:" >&AC_FD_LOG
Index: aclang.m4
===
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.68
diff -u -r1.68 aclang.m4
--- aclang.m4 2000/10/02 13:11:28 1.68
+++ aclang.m4 2000/10/11 10:00:24
@@ -523,7 +520,7 @@
[# 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
+ if AC_TRY_COMMAND(./conftest$ac_exeext); then
cross_compiling=no
else
if test "$cross_compiling" = maybe; then
@@ -796,9 +793,9 @@
# Make sure it works both with $CC and with simple cc.
# We do the test twice because some compilers refuse to overwrite an
# existing .o file with -o, though they will create one.
-ac_try='${CC-cc} -c conftest.$ac_ext -o conftest.$objext >&AC_FD_LOG'
+ac_try='${CC-cc} -c conftest.$ac_ext -o conftest.$ac_objext >&AC_FD_LOG'
if AC_TRY_EVAL(ac_try) &&
- test -f conftest.$objext && AC_TRY_EVAL(ac_try);
+ test -f conftest.$ac_objext && AC_TRY_EVAL(ac_try);
then
eval ac_cv_prog_cc_${ac_cc}_c_o=yes
if test "x$CC" != xcc; then
@@ -806,7 +803,7 @@
if AC_TRY_COMMAND(cc -c conftest.$ac_ext >&AC_FD_LOG); then
ac_try='cc -c conftest.$ac_ext -o conftest.$ac_objext >&AC_FD_LOG'
if AC_TRY_EVAL(ac_try) &&
-test -f conftest.$objext && AC_TRY_EVAL(ac_try);
+test -f conftest.$ac_objext && AC_TRY_EVAL(ac_try);
then
# cc works too.
:
@@ -1089,8 +1086,8 @@
# We do the `AC_TRY_EVAL' test twice because some compilers refuse to
# overwrite an existing `.o' file with `-o', although they will create
# one.
-ac_try='$F77 $FFLAGS -c conftest.$ac_ext -o conftest.$objext >&AC_FD_LOG'
-if AC_TRY_EVAL(ac_try) && test -f conftest.$objext && AC_TRY_EVAL(ac_try); then
+ac_try='$F77 $FFLAGS -c conftest.$ac_ext -o conftest.$ac_objext >&AC_FD_LOG'
+if AC_TRY_EVAL(ac_try) && test -f conftest.$ac_objext && AC_TRY_EVAL(ac_try); then
ac_cv_prog_f77_c_o=yes
else
ac_cv_prog_f77_c_o=no
Re: [PATCH] A better (?) _AC_EXEEXT
* Akim | [...] Your patch, as is, does not solve [...] I know, I know. I don't claim the patch to be perfect, I'm just saying that it is _better_ than the code it replaces. :^} | [...] since AC_PROG_CC launches AC_EXEEXT which uses AC_LINK_IFELSE | which requires AC_PROG_CC, autoconf should and will fail. This is | the circular dependency I'm referring to. | | AC_LINK_IFELSE must keep its AC_REQUIRE on AC_PROG_CC, hence you | must not use AC_LINK_IFELSE. That's why I first suggested using | AC_TRY_EVAL: to avoid the AC_REQUIRE. Yes, I was aware of that problem -- I just can't think of a good way to solve it at the moment. | You may call AC_CANONICAL_TARGET (while AC_CANONICAL_HOST is more | logical), but you must depend on the *_host variables, *not* the | target vars. See the doc for more details. I think the attached patch will at least improve the situation a little bit. I couldn't find anything from config.guess matching the EMX/OS2 stuff, though. Regards, Morten Index: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.897 diff -u -r1.897 ChangeLog --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/11 10:42:34 @@ -1,3 +1,9 @@ +2000-10-11 Morten Eriksen <[EMAIL PROTECTED]> + + * acspesific.m4 (_AC_CYGWIN, _AC_MINGW32): Avoid false negatives + when using compilers which do not set up special defines on these + platforms. + 2000-10-05 Akim Demaille <[EMAIL PROTECTED]> Check that updated scripts are valid scripts. Index: acspecific.m4 === RCS file: /cvs/autoconf/acspecific.m4,v retrieving revision 1.300 diff -u -r1.300 acspecific.m4 --- acspecific.m4 2000/10/02 12:47:13 1.300 +++ acspecific.m4 2000/10/11 10:42:35 @@ -1496,25 +1496,21 @@ # _AC_CYGWIN # -- -# Check for Cygwin. This is a way to set the right value for -# EXEEXT. +# Check for Cygwin. define([_AC_CYGWIN], -[AC_CACHE_CHECK(for Cygwin environment, ac_cv_cygwin, -[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], -[#ifndef __CYGWIN__ -# define __CYGWIN__ __CYGWIN32__ -#endif -return __CYGWIN__;])], - [ac_cv_cygwin=yes], - [ac_cv_cygwin=no])]) +[AC_REQUIRE([AC_CANONICAL_HOST])dnl +AC_CACHE_CHECK(for Cygwin environment, ac_cv_cygwin, +[case "$host_os" in + cygwin*) ac_cv_cygwin=yes ;; + *) ac_cv_cygwin=no ;; +esac]) test "$ac_cv_cygwin" = yes && CYGWIN=yes[]dnl ])# _AC_CYGWIN # _AC_EMXOS2 # -- -# Check for EMX on OS/2. This is another way to set the right value -# for EXEEXT. +# Check for EMX on OS/2. define([_AC_EMXOS2], [AC_CACHE_CHECK(for EMX OS/2 environment, ac_cv_emxos2, [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [return __EMX__;])], @@ -1526,13 +1522,14 @@ # _AC_MINGW32 # --- -# Check for mingw32. This is another way to set the right value for -# EXEEXT. +# Check for mingw32. define([_AC_MINGW32], -[AC_CACHE_CHECK(for mingw32 environment, ac_cv_mingw32, -[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [return __MINGW32__;])], - [ac_cv_mingw32=yes], - [ac_cv_mingw32=no])]) +[AC_REQUIRE([AC_CANONICAL_HOST])dnl +AC_CACHE_CHECK(for mingw32 environment, ac_cv_mingw32, +[case "$host_os" in + mingw32*) ac_cv_mingw32=yes ;; + *) ac_cv_mingw32=no ;; +esac]) test "$ac_cv_mingw32" = yes && MINGW32=yes[]dnl ])# _AC_MINGW32
Re: [PATCH] A better (?) _AC_EXEEXT
* Akim | Then let me restate my question: why don't you use AC_TRY_EVAL just | like in AC_EXEXT: this is a good first step I think. Umm.. I assume you mean to ask "why not use AC_TRY_EVAL in AC_EXEEXT just like in AC_OBJEXT" (and not "..like in AC_EXEEXT")? If so, my question for you is then: what should AC_TRY_EVAL evaluate? I can't think of any suitable command which would uncover how to use executable suffices on the system -- without already _knowing_ the suffix. :^/ Note that AC_TRY_EVAL(ac_link) is _not_ the correct answer, as ac_link contains a reference to $ac_exeext (which of course means a circular dependency back to AC_EXEEXT). Regards, Morten
Re: [PATCH] A better (?) _AC_EXEEXT
* Akim | I agree there are *two* issues. One is that there is a AC_REQUIRE | circular dependency because AC_EXEXT uses AC_LINK_IFELSE, the other | is that both AC_LINK_IFELSE and AC_TRY_EVAL(ac_link) are | inappropriate here. Aha. How about the attached patch, then? Regards, Morten Index: ChangeLog === RCS file: /cvs/autoconf/ChangeLog,v retrieving revision 1.897 diff -u -r1.897 ChangeLog --- ChangeLog 2000/10/05 13:52:41 1.897 +++ ChangeLog 2000/10/11 09:28:11 @@ -1,3 +1,9 @@ +2000-10-11 Morten Eriksen <[EMAIL PROTECTED]> + + * acspecific.m4 (_AC_EXEEXT): Change of strategy for the macro, we + now search for a valid executable suffix. The old code had circular + dependencies which basically made it fubar. + 2000-10-05 Akim Demaille <[EMAIL PROTECTED]> Check that updated scripts are valid scripts. Index: acspecific.m4 === RCS file: /cvs/autoconf/acspecific.m4,v retrieving revision 1.300 diff -u -r1.300 acspecific.m4 --- acspecific.m4 2000/10/02 12:47:13 1.300 +++ acspecific.m4 2000/10/11 15:14:45 @@ -1554,35 +1554,37 @@ # _AC_EXEEXT # -- -# Check for the extension used for executables. This knows that we -# add .exe for Cygwin or mingw32. Otherwise, it compiles a test -# executable. If this is called, the executable extensions will be -# automatically used by link commands run by the configure script. +# Check for a valid extension to use for executables. define([_AC_EXEEXT], -[_AC_CYGWIN -_AC_MINGW32 -_AC_EMXOS2 -AC_CACHE_CHECK([for executable suffix], ac_cv_exeext, -[case "$CYGWIN $MINGW32 $EMXOS2" in - *yes*) ac_cv_exeext=.exe ;; - *) - AC_LINK_IFELSE([AC_LANG_PROGRAM()], - [if test ! -f conftest; then -for ac_file in conftest.*; do - case $ac_file in - *.$ac_ext | *.o | *.obj | *.xcoff) ;; - *) ac_cv_exeext=`expr "$ac_file" : 'conftest\(.*\)'`;; - esac - done - fi], - [AC_MSG_ERROR([cannot compile and link])]) - test -n "$ac_cv_exeext" && ac_cv_exeext=no;; -esac]) -EXEEXT= -test "$ac_cv_exeext" != no && EXEEXT=$ac_cv_exeext -dnl Setting ac_exeext will implicitly change the ac_link command. -ac_exeext=$EXEEXT -AC_SUBST(EXEEXT)dnl +[AC_CACHE_CHECK([for executable suffix], ac_cv_exeext, +[# Try to compile and link an executable with no suffix first. +ac_exeext= +AC_LANG_CONFTEST([AC_LANG_PROGRAM()]) +if AC_TRY_EVAL(ac_link); then + # Ok, we can use an empty suffix for executables. Now see if the + # executable with the empty suffix is just a filesystem mapping + # from the real file (this happens under Cygwin, for instance). + if (test conftest -ef conftest.exe) >/dev/null 2>&1; then +# Prefer .exe over empty suffix. +ac_cv_exeext=.exe + else +ac_cv_exeext= + fi +else + # Couldn't use empty suffix, try with suffix commonly used + # on MSWindows platforms. + ac_exeext=.exe + if AC_TRY_EVAL(ac_link); then +ac_cv_exeext=.exe + else +rm -f conftest.$ac_ext conftest.$ac_objext +AC_MSG_ERROR(cannot compile and link) + fi +fi +]) +rm -f conftest.$ac_ext conftest.$ac_objext conftest.$ac_exeext +EXEEXT=$ac_cv_exeext +AC_SUBST(EXEEXT) ])# _AC_EXEEXT
Re: AC_PROG_CC not working
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> [...] I mean if you do cc conftest.c -o conftest, and afterwards
> there is no file "conftest", but there is a file "conftest.exe" that
> wasn't there before, that should be pretty conclusive, no?
Not really, no. For instance, Cygwin does this funny thing where they
map all files named ``something.exe'' to also match any inquires to a
file named ``something''.
So you could do:
$ cat > conftest.c
int main(void) { return 0; }
^D
$ gcc -o conftest.exe conftest.c
$ ls
conftest.exe conftest.c
$ ls conftest
conftest
$
And further:
$ rm conftest.exe
$ ls conftest*
conftest.c
$ gcc -o conftest conftest.c
$ ls
conftest.exe conftest.c
$
(So, in the Cygwin case it doesn't really matter whether you set the
executable suffix to ".exe" or "", I guess.)
Regards,
Morten
Re: AC_PROG_CC not working
* Pavel Roskin | Since EXEEXT="" makes "cp" fail it's not a good choice. So instead | of doing "test contest -ef contest.exe" do "cp contest contest.ac_" | and reverse the logic (i.e. if "cp" fails we use ".exe") Well, I don't think this is such a good idea. What if the Cygwin port of ``cp'' is suddenly made to work correctly with that filesystem voodoo Cygwin does, but other programs are still defunct? Instead of chasing possible problems with Cygwin's little magic trick, isn't it better to just try to detect it and circumvent it completely? (As I try to do with the AC_EXEEXT patch.) Regards, Morten
Bug: explicitly setting CC made defunct
Hi, a bug has been introduced by one of the commits from the last day or so. Upon this configure.in file AC_INIT(configure.in) AC_PROG_CC autoconf (fresh from the head CVS) generates a configure script which produces this output when run as "./configure CC=foobar" checking for gcc... no checking for cc... no checking for cc... no checking for cl... cl checking whether the C compiler works... yes checking whether we are cross compiling... no checking whether we are using the GNU C compiler... no checking whether cl accepts -g... no checking for object suffix... obj checking for executable suffix... .exe As you can see, the CC-variable is not heeded. Ouch. Regards, Morten
Re: Bug: explicitly setting CC made defunct
Akim Demaille <[EMAIL PROTECTED]> writes: > Thanks, I'm sure I'm responsible for this. Most certainly my recent > changes involving AC_CHECK_TOOLS. I'm on it. Don't bother, I nailed it down. Patch coming up. Morten
Re: Bug: explicitly setting CC made defunct
Akim Demaille <[EMAIL PROTECTED]> writes:
> >>>>> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
>
> Morten> Hi, a bug has been introduced by one of the commits from the
> Morten> last day or so. Upon this configure.in file
>
> Morten> AC_INIT(configure.in) AC_PROG_CC
>
> Thanks, I'm sure I'm responsible for this. Most certainly my recent
> changes involving AC_CHECK_TOOLS. I'm on it.
Ok, here's the fix:
Index: acgeneral.m4
===
RCS file: /cvs/autoconf/acgeneral.m4,v
retrieving revision 1.578
diff -u -r1.578 acgeneral.m4
--- acgeneral.m42000/10/17 12:48:51 1.578
+++ acgeneral.m42000/10/17 15:49:47
@@ -3197,6 +3197,7 @@
AC_CHECK_PROG([$1], [${ac_tool_prefix}$2], [${ac_tool_prefix}$2], , [$4])
fi
if test -z "$ac_cv_prog_$1"; then
+ ac_ct_$1=$$1
AC_CHECK_PROG([ac_ct_$1], [$2], [$2], [$3], [$4])
$1="$ac_ct_$1"
fi
@@ -3220,7 +3221,9 @@
done
fi
if test -z "$$1"; then
- AC_CHECK_PROGS([$1], [$2], [$3], [$4])
+ ac_ct_$1=$$1
+ AC_CHECK_PROGS([ac_ct_$1], [$2], [$3], [$4])
+ $1="ac_ct_$1"
fi
])# AC_CHECK_TOOLS
The bug was actually old, but was never uncovered due to the fact that
the AC_CHECK_PROG within the first if-block was always executed, even
if $ac_tool_prefix was blank. This was correctly fixed by you in your
patch, but you overlooked the bug which then got uncovered. :^/
Note that the patch also contains the same fix for AC_CHECK_TOOLS
aswell.
Here's the changelog entry:
2000-10-17 Morten Eriksen <[EMAIL PROTECTED]>
* acgeneral.m4 (AC_CHECK_TOOL[S]?): As AC_CHECK_PROG[S]? first
tests the value of the VARIABLE argument when looking for
executables in the PATH, we need to set it to the correct
value from AC_CHECK_TOOL[S]? when not just passing on the
incoming VARIABLE directly.
(What happened with the CC=foobar case was that AC_CHECK_TOOL(CC, gcc)
called AC_CHECK_PROG(ac_ct_CC, gcc). But ac_ct_CC didn't contain the
value of CC, of course.)
Regards,
Morten
Re: Bug: explicitly setting CC made defunct
Akim Demaille <[EMAIL PROTECTED]> writes: > | 2000-10-17 Morten Eriksen <[EMAIL PROTECTED]> > | > | * acgeneral.m4 (AC_CHECK_TOOL[S]?): As AC_CHECK_PROG[S]? first > | tests the value of the VARIABLE argument when looking for > | executables in the PATH, we need to set it to the correct > | value from AC_CHECK_TOOL[S]? when not just passing on the > | incoming VARIABLE directly. > > I like your patch better than mine. I'm installing it (my distcheck > is still running so my previous patch is not applied yet). It looks like you caught some cases which I missed, but your fixes looks flawed in several ways. I'll think about this some more and perhaps submit further patches. Anyway, feel free to go ahead and apply my first patch. I can't see that it could possibly introduce any new bugs and I've tested that it actually fixes what it is supposed to fix. Morten
Re: Where did the Cygwin and Mingw checks go?
* Mo DeJong > I was under the impression that autoconf would just try to compile > conftest.c and then find the obj extension by looking for files > named conftest.*, filtering out conftest.c and then using whatever > was left (either conftest.o or conftest.obj). That might have > changed, but it seems to be the way I remember it. That's the way it is supposed to work, yes. Regards, Morten (the last person to (re)write AC_OBJEXT)
[BUG] AC_PATH_XTRA
Hi, given this configure.in (a useless case, but it'll serve as an example): == [snip] AC_INIT(configure.in) AC_CONFIG_HEADER(config.h) if false; then AC_PATH_XTRA else AC_PATH_XTRA fi AC_OUTPUT == [snip] ..the resulting configure script will fail to define X_DISPLAY_MISSING on systems without X11. The reason for this is that AC_PATH_XTRA AC_REQUIREs AC_PATH_X, which means it will only get expanded for the _first_ AC_PATH_XTRA in the configure.in above, and then AC_PATH_XTRA uses test x"$no_x" = xyes to decide whether or not to define X_DISPLAY_MISSING. But the AC_PATH_X code will never be executed for the second AC_PATH_XTRA above, so $no_x will never be set to anything at all. (Autoconf's X11 checking is in general a mess, BTW.) Regards, Morten
Re: Where did the Cygwin and Mingw checks go?
Paul Berrevoets <[EMAIL PROTECTED]> writes: > [...] for AC_EXEEXT please take into consideration that on UWIN > (which uses a cc wrapper for MSVC), the compiler also generates a > .pdb file, which if you don't filter it out along with .obj, would > be used as the extension for executables. I've had a patch in the pipeline for AC_EXEEXT for quite some time now, which would not fall into the trap you decribe. See below. There was a lot of discussion and many rewrites, but I don't think I ever got a definitive "no" on the (so far) final version below. I even think I got at least one "yes" from one of the maintainers, so I really don't know why it wasn't applied. Regards, Morten Index: acspecific.m4 === RCS file: /cvs/autoconf/acspecific.m4,v retrieving revision 1.313 diff -u -r1.313 acspecific.m4 --- acspecific.m4 2000/11/14 16:01:05 1.313 +++ acspecific.m4 2000/11/15 12:03:11 @@ -1199,32 +1199,32 @@ # _AC_EXEEXT # -- -# Check for the extension used for executables. This knows that we -# add .exe for Cygwin or mingw32. Otherwise, it compiles a test -# executable. If this is called, the executable extensions will be -# automatically used by link commands run by the configure script. +# Check for a valid extension to use for executables. m4_define([_AC_EXEEXT], [AC_CACHE_CHECK([for executable suffix], ac_cv_exeext, -[case "$CYGWIN $MINGW32 $EMXOS2" in - *yes*) ac_cv_exeext=.exe ;; - *) - _AC_LINK_IFELSE([AC_LANG_PROGRAM()], - [if test ! -f conftest; then -for ac_file in conftest.*; do - case $ac_file in - *.$ac_ext | *.o | *.obj | *.xcoff) ;; - *) ac_cv_exeext=`expr "$ac_file" : 'conftest\(.*\)'`;; - esac - done - fi], - [AC_MSG_ERROR([cannot compile and link])]) - test -n "$ac_cv_exeext" && ac_cv_exeext=no;; -esac]) -EXEEXT= -test "$ac_cv_exeext" != no && EXEEXT=$ac_cv_exeext -dnl Setting ac_exeext will implicitly change the ac_link command. -ac_exeext=$EXEEXT -AC_SUBST(EXEEXT)dnl +[# Try to compile and link an executable with no suffix first. +ac_exeext= +_AC_LINK_IFELSE([AC_LANG_PROGRAM()], + [# Ok, we can use an empty suffix for executables. Now see if the + # executable with the empty suffix is just a filesystem mapping + # from the real file (this happens under Cygwin, for instance). + if (test conftest -ef conftest.exe) >/dev/null 2>&1; then +# Prefer .exe over empty suffix (to avoid depending +# on the Cygwin filesystem voodoo, which is known to fail +# with certain tools/commands). +ac_exeext=.exe + fi], + [# Couldn't use empty suffix, try with suffix commonly used + # on DOS-based platforms. + ac_exeext=.exe + _AC_LINK_IFELSE([AC_LANG_PROGRAM()], [], + [rm -f conftest.$ac_ext conftest.$ac_objext +AC_MSG_ERROR([cannot compile and link])]) + ]) +ac_cv_exeext=$ac_exeext +]) +ac_exeext=$ac_cv_exeext +AC_SUBST(EXEEXT, $ac_exeext) ])# _AC_EXEEXT
Re: AC_OBJEXT again
Akim Demaille <[EMAIL PROTECTED]> writes: > OBJEXT and EXEEXT [...] define precisely what they are (build, or > host?), [...] Just wanted to add my 0.02 Kroner: after pondering this issue for a while, I tend to believe we should first and foremost view them as characteristics of the _compiler_ -- screw looking at the host and build system. :-) Regards, Morten
Re: Release next week?
Akim Demaille <[EMAIL PROTECTED]> writes: [About changing language for a future Autoconf rewrite] > No really, I think Perl is the most serious candidate. Check out this snippet from Automake's TODO file: rewrite in guile (RMS request) at the same time, consider adding a GUI could use the same parsing code for the GUI and the standalone version that means figuring out a better representation of internal state [ that's easy -- anything is better than what we have now ] (It seems a bit silly to go from sh to Perl with Autoconf if Automake is planned to be rewritten from Perl to Guile..) :-} Regards, Morten
