link and run a (fortran) program redirecting its stdout/stderr

[Stefano Lattarini]

Hello.

I have to compile and link a Fortran 77 test program. and then run it
redirecting its stdout/stderr (I need to do so to verify that the `stop'
builtin is silent when called without arguments -- unfortunately this is
not always the case, e.g. when using gfortran-4.0).

I thought at first to use AC_RUN_IFELSE, but it doesn't seem to offer
a way to redirect the stdout/stderr of the program it runs.

So I thought to use AC_LINK_IFELSE instead, and then run the
linked program by hand, doing the proper redirections (as well
logging to `config.log') by hand. Unfortunately, the code created
by AC_LINK_IFELSE removes the linked program (among the other
things), thus it's useless for me.

And obviously, I don't want to dive in autoconf internals, starting
to use stuff like `$ac_compile' or `ac_fn_f77_try_link' (I think the
reasons against this approach are so many and so abvious not to
require any further explanation).

So I'm stuck.  Do you have any advice about how to accompilsh my
intended purpose?  Any help would be appreciated.

Regards,
    Stefano


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Stefano Lattarini wrote on Mon, Oct 12, 2009 at 09:20:04PM CEST:
> I have to compile and link a Fortran 77 test program. and then run it
> redirecting its stdout/stderr (I need to do so to verify that the `stop'
> builtin is silent when called without arguments -- unfortunately this is
> not always the case, e.g. when using gfortran-4.0).

Can you explain what this means or does?  If this is similar to checking
for the declaration of a C function, then it should be handled
similarly, i.e., by a suitable compile or link test, rather than by
trying to parse compiler and/or output.

The latter is very brittle.  Libtool tries to do it in its
_LT_{COMPILER,LINKER}_OPTION macros, and it's only causing trouble.

Thanks,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stefano Lattarini]

At Tuesday 13 October 2009, Ralf Wildenhues <Ralf.Wildenhues@...> wrote:

> * Stefano Lattarini wrote on Mon, Oct 12, 2009 at 09:20:04PM CEST:
> > I have to compile and link a Fortran 77 test program. and then
> > run it redirecting its stdout/stderr (I need to do so to verify
> > that the `stop' builtin is silent when called without arguments
> > -- unfortunately this is not always the case, e.g. when using
> > gfortran-4.0).
>
> Can you explain what this means or does?  If this is similar to
> checking for the declaration of a C function, then it should be
> handled similarly, i.e., by a suitable compile or link test, rather
> than by trying to parse compiler and/or output.

OK, I must admit that the description of my intentions was really badly
expressed.  I'll try to restate them more clearly.

I *don't* care about compiler warnings or messages at compile time.

What matters to me is that the *program generated* by the compiler,
when executed, is not too verbose w.r.t. the `stop' builtin.

For example, assume that I have a fortran source using the `stop'
builtin *without arguments*, as in:
 
  $ cat foo.f
        program foo
        stop
        end

If I compile the `foo.f' file into the `foo.exe' executable:
  $ f77 -o foo.exe foo.f
then I'd expect that running `foo.exe' will simply produce a sucessful
exit status, and *no message* on stdout or stderr.  This is indeed what
happens with "modern" gfortran (version 4.3) and with the `fort77'
compiler (wrapper arounf f2c + gcc): the generated program behaves
as expected, being completely quiet.

Unfortunately, the foo.exe produced by gfortran-4.0 ends up doing
someting like this:
  $ gfortran-4.0 -o foo.exe foo.f  # no errors or warnings here
  $ ./foo.exe  # this produces the following unwanted message
  STOP 0

To summarize, what I must verify is that the Fortran compiler, when
processing a call to `stop' *without arguments*, does not produce code
which, when executed, will end up writing "STOP 0" or sometinhg similar
on stdout/stderr.  The only way I can think of to accomplish this is to
compile and link a simple test program (like the `foo.f' above), run it
redirecting its output, and analyze this output.  And here I'm stuck,
for the problems described in my previous mail.

Hope things are clearer now.

Thanks,
     Stefano


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Stefano Lattarini wrote on Tue, Oct 13, 2009 at 03:22:51PM CEST:
> What matters to me is that the *program generated* by the compiler,
> when executed, is not too verbose w.r.t. the `stop' builtin.

Then you should be able to use AC_RUN_IFELSE.  To allow for cross
compilation, in the fourth argument you could try to find out which
versions of gfortran have this issue, and check for those versions
there (probably easiest done by GCC-specific preprocessor conditionals).

HTH.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stefano Lattarini]

At Tuesday 13 October 2009, Ralf Wildenhues <Ralf.Wildenhues@...>
wrote:
> * Stefano Lattarini wrote on Tue, Oct 13, 2009 at 03:22:51PM CEST:
> > What matters to me is that the *program generated* by the
> > compiler, when executed, is not too verbose w.r.t. the `stop'
> > builtin.
>
> Then you should be able to use AC_RUN_IFELSE.
But in the documentation of AC_RUN_IFELSE, as found at:
  http://www.gnu.org/software/autoconf/manual/autoconf.html#Runtime
I can't find any mention of files where the stdout/stderr of the test
program is saved.  And I known in advance that the test program will
succeed: what I must verify is that it won't write anything on stdout
or stderr.  In this respect, AC_RUN_IFELSE does not seem helpful.
Was I misunderstood, or am I missing something?

> To allow for cross
> compilation, in the fourth argument you could try to find out which
> versions of gfortran have this issue, and check for those versions
> there (probably easiest done by GCC-specific preprocessor
> conditionals).
Luckily, cross compilation is not an issue here: my package is a
simple testsuite for ratfor, and I need the fortran compiler only to  
build test programs from fortran sources generated by ratfor; this
test programs must then be run on the spot, so that a native compiler
is needed anyway.

Regards,
   Stefano


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Stefano Lattarini wrote on Tue, Oct 13, 2009 at 08:39:11PM CEST:

> At Tuesday 13 October 2009, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Tue, Oct 13, 2009 at 03:22:51PM CEST:
> > > What matters to me is that the *program generated* by the
> > > compiler, when executed, is not too verbose w.r.t. the `stop'
> > > builtin.
> >
> > Then you should be able to use AC_RUN_IFELSE.
> But in the documentation of AC_RUN_IFELSE, as found at:
>   http://www.gnu.org/software/autoconf/manual/autoconf.html#Runtime
> I can't find any mention of files where the stdout/stderr of the test
> program is saved.  And I known in advance that the test program will
> succeed: what I must verify is that it won't write anything on stdout
> or stderr.  In this respect, AC_RUN_IFELSE does not seem helpful.

Sorry; I forgot to add: In the ACTION-IF-TRUE argument of AC_RUN_IFELSE,
you can invoke ./conftest$EXEEXT yourself and see what it does.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stefano Lattarini]

At Wednesday 14 October 2009, Ralf Wildenhues <Ralf.Wildenhues@...>
wrote:
> Sorry; I forgot to add: In the ACTION-IF-TRUE argument of
> AC_RUN_IFELSE, you can invoke ./conftest$EXEEXT yourself and see
> what it does.
Oh.  This is exactly what I need.  Thank you very much!

Maybe the autoconf documentation might be clearer on this point.

Thanks again,
    Stefano


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Stefano Lattarini on 10/14/2009 3:52 AM:
>> Sorry; I forgot to add: In the ACTION-IF-TRUE argument of
>> AC_RUN_IFELSE, you can invoke ./conftest$EXEEXT yourself and see
>> what it does.
> Oh.  This is exactly what I need.  Thank you very much!
>
> Maybe the autoconf documentation might be clearer on this point.

Good idea.  Done:

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrnqjgACgkQ84KuGfSFAYCE+wCgu0R4u3CID1hUvtmkSfrHehgs
+5kAoICf/dMiFz6Xz/BVfGoZAVLoWrEk
=GF3p
-----END PGP SIGNATURE-----

From a7ae50526b7a526b9f297288dc5a5adeb30cf544 Mon Sep 17 00:00:00 2001
From: Eric Blake <ebb9@...>
Date: Tue, 27 Oct 2009 20:14:14 -0600
Subject: [PATCH] Mention another feature of AC_RUN_IFELSE.

* doc/autoconf.texi (Runtime) <AC_RUN_IFELSE>: Mention that
compiled test program still exists during if-true branch.

Signed-off-by: Eric Blake <ebb9@...>
---
 ChangeLog         |    7 +++++++
 doc/autoconf.texi |    2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4f93ee3..95808ed 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
[phone]  Eric Blake  <ebb9@...>
+
+ Mention another feature of AC_RUN_IFELSE.
+ * doc/autoconf.texi (Runtime) <AC_RUN_IFELSE>: Mention that
+ compiled test program still exists during if-true branch.
+ Reported by Stefano Lattarini, suggestion by Ralf Wildenhues.
+
 2009-10-26  Paolo Bonzini  <bonzini@...>

  Pass Autom4te path down to programs that autoreconf invokes.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index db8c88e..a713a06 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8952,6 +8952,8 @@ Runtime
 The @var{input} can be made by @code{AC_LANG_PROGRAM} and friends.
 @code{LDFLAGS} and @code{LIBS} are used for linking, in addition to the
 compilation flags of the current language (@pxref{Language Choice}).
+Additionally, @var{action-if-true} can run @command{./conftest$EXEEXT}
+for further testing.

 If the compiler being used does not produce executables that run on the
 system where @command{configure} is being run, then the test program is
--
1.6.5.rc1


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Eric Blake wrote on Wed, Oct 28, 2009 at 03:19:37AM CET:
> According to Stefano Lattarini on 10/14/2009 3:52 AM:
> >> Sorry; I forgot to add: In the ACTION-IF-TRUE argument of
> >> AC_RUN_IFELSE, you can invoke ./conftest$EXEEXT yourself and see
> >> what it does.
> > Oh.  This is exactly what I need.  Thank you very much!
> >
> > Maybe the autoconf documentation might be clearer on this point.
>
> Good idea.  Done:

Should we also document that the ACTION-IF-TRUE part of
AC_LINK_IFELSE allows linked programs to be inspected (not necessarily
run) and that of AC_COMPILE_IFELSE allows compiled objects to be
inspected?  And add testsuite exposure to each?

/me tries to remember what the difference between $OBJEXT and
$ac_objext, and between $EXEEXT and $ac_ext was again ...

Thanks,
Ralf

>  The @var{input} can be made by @code{AC_LANG_PROGRAM} and friends.
>  @code{LDFLAGS} and @code{LIBS} are used for linking, in addition to the
>  compilation flags of the current language (@pxref{Language Choice}).
> +Additionally, @var{action-if-true} can run @command{./conftest$EXEEXT}
> +for further testing.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf