bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

autoconf (2.57 or earlier), AC_SEARCH_LIBS(), AC_CHECK_FUNCS(), and C++


From: Nelson H. F. Beebe
Subject: autoconf (2.57 or earlier), AC_SEARCH_LIBS(), AC_CHECK_FUNCS(), and C++
Date: Fri, 3 Jan 2003 08:08:40 -0700 (MST)

In autoconf (2.57 or earlier), AC_SEARCH_LIBS() and AC_CHECK_FUNCS()
generate test code like this:

        #include <stdlib.h>

        /* 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 strtol ();

        int
        main ()
        {
            strtol ();
            return 0;
        }

This works correctly in C environments, but is questionable under C++,
because <stdlib.h> will have a declaration that probably looks like
this:

        extern "C" long strtol (const char *, char **, int);

while the test code has

        extern "C" char strtol ();

I routinely build code up to 16 different UNIX platforms with more
than 60 C and C++ compilers, preferring C++ compilers over C ones
for my C code for enhanced type checking.

On at least two systems, HP/Compaq/DEC OSF/1 5.1 and SGI IRIX 6.5,
the vendor-provided native compilers reject autoconf's test code
with errors like this:

        More than one instance of overloaded function "strtol" has "C" linkage.

        char strtol ();
             ^

I believe that there is a better way for configure to test for
function availability.

Instead of generating a possibly-conflicting prototype for a
function-availability test, avoid the prototype altogether, and cast
the function name to a function of another type that IS properly
declared:

        #include <stdlib.h>

        #if __cplusplus
        #define VOID void
        #else
        #define VOID
        #endif

        void (*fun)(VOID);

        int
        main ()
        {
            fun = (void (*)(VOID)) strtol;
            (*fun) ();
            return 0;
        }

This code compiles, and links, successively with the two C++ compilers
that otherwise reject the current tests, and also with every other C
and C++ compiler that I checked.  Of course, the resulting program
cannot be run since the function arguments are not correct.

For a run test, the following test code works, since it only takes the
address of the test function: for maximum portability, that address is
printed as a long integer value with space for an up-to 64-bit result,
since we cannot assume the availability of C89's %p format item.
[On Alpha systems running either OSF/1 or GNU/Linux, addresses are
above the 32-bit barrier, unless a special compiler option (-taso with
native compilers, but no similar option with gcc/g++) is used to
request a 32-bit addressing limit.]

        #include <stdio.h>
        #include <stdlib.h>

        #if __cplusplus
        #define VOID void
        #else
        #define VOID
        #endif

        void (*fun)(VOID);

        int
        main ()
        {
            fun = (void (*)(VOID)) strtol;
            printf("%s is at 0x%016lx\n", "strtol", (unsigned long int)fun);
            return 0;
        }

This code is careful to work only with pointers to functions, since
the C Standards permit such pointers to have a different size than
pointers to other objects (such behavior is the case on some HP
systems).

In either case, my proposed alternate test code works correctly on
every system that I've tested, including the two that reject the
current autoconf test code.

If the function is not declared in the system header file, then
compilation will fail with an undeclared-variable error in the
assignment to fun.  The current autoconf test does not have this
behavior: compilation, and even linking, might succeed if a header
file prototype is missing, but the function is available in the
run-time library.

In practice, only the second test program is needed, but it does
demand the availability of <stdio.h> and printf(): while these are
available in hosted environments, they might not be in embedded ones,
but then, I suspect many other autoconf tests will fail too.

Comments?

Examination of our /usr/local/share/autoconf/ tree shows six places
where the comment "We use char...." occurs, two in aclang.m4 and four
in autoconf.m4.  However, there are likely other places where similar
faulty test code is buried, so it would be better for folks more
familiar with the autoconf source code than I am to make the patches.

If someone cares to offer some patches to autoconf to implement these
ideas, I'll test them with every compiler that I have access to.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 581 4148                  -
- University of Utah                    Internet e-mail: address@hidden  -
- Department of Mathematics, 110 LCB        address@hidden  address@hidden -
- 155 S 1400 E RM 233                       address@hidden                    -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]