Is there a reason that you need to use c99? We've never tested LAM
against that, and clearly one of our configure tests doesn't always do
the right thing in the presence of that flag.
I'm guessing that you don't need this flag to build LAM itself. Even
if your apps use that flag, I don't think that it would create any
interoperability problems if LAM is compiled without it. For example,
I strongly doubt (although I don't know for 100% sure) that libc is
compiled with c99. Check the compiler manual to be sure, but I don't
think that it will create any problems.
On Oct 5, 2004, at 6:20 PM, E. Robert Tisdale wrote:
> lam-7.1.1> ./configure
> .
> .
> .
> *** Optional modules
> checking if want MPI C++ bindings... enabled
> checking size of int... 4
> checking size of bool... 1
> checking type of MPI attributes... long
> checking for signal declaration... not found
> configure: error: cannot determine if signals are bsd/sysv
>
> The problem seems to be in signal.h
>
> lam-7.1.1> cat config.log
> .
> .
> .
> | #include<signal.h>
> | extern "C" void sysv_handler(int sig) {};
> |
> | int
> | main ()
> | {
> | signal(1, sysv_handler);
> |
> | ;
> | return 0;
> | }
> configure:25480: result: not found
> configure:25482: error: cannot determine if signals are bsd/sysv
> .
> .
> .
>
> I use the GNU C compiler:
>
> lam-7.1.1> gcc --version
> gcc (GCC) 3.4.1
>
> with options:
>
> lam-7.1.1> printenv CFLAGS
> -Wall -std=c99 -pedantic -O3
>
> The problem appears to be that
>
> lam-7.1.1> cat /usr/include/signal.h
> .
> .
> .
> #ifdef __USE_POSIX
> .
> .
> .
> # include <bits/siginfo.h>
> .
> .
> .
> # endif
> .
> .
> .
>
> the signal.h header file will *not* include the bits/siginfo.h
> header file unless __USE_POSIX is defined
> but my GNU C compiler will *not* allow __USE_POSIX
> to be defined when i use the -std=c99 option.
>
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
