Re: AC_F77_NAME_MANGLING question

| AC_TRY_LINK_FUNC(${ac_foo_bar}, f77_underscore=double) | | I have the following question: To my understanding, if linking | "foobar" succeeds, $f77_underscore=no, and $ac_foo_bar=foo_bar_. | Now, if linking foo_bar_ succeeds as well in the second AC_LINK_FUNC | statement, f77_underscore wil

Re: AC_F77_NAME_MANGLING question

Akim Demaille wrote: > I think you are right. Maybe the author meant > >AC_TRY_LINK_FUNC($ac_foo_bar, [], [f77_underscore=double]) > Patches are welcome :) I don't like to mess with this macro until I understand the original author's intention. So far the macro didn't produce errors on an

Re: AC_F77_NAME_MANGLING question

Hi John, Below we have a question regarding AC_F77_NAME_MANGLING, which, I think, you wrote. Akim Topics: AC_F77_NAME_MANGLING question Re: AC_F77_NAME_MANGLING question Re: AC_F77_NAME_MANGLING question ---

Re: autoconf fortran 90 support

| > By no way should it be the user. That's probably something easy to | > test and set. Just set ac_ext to ac_cv_prog_f90_ac_ext in | > AC_LANG(Fortran 90) and compute the latter in AC_PROG_F90. That | > should be enough? | | The user must specify his source files with one or the other suffi

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

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

Re: This configure.in script does not work with autoconf 2.14

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 :)

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

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

Re: Should gcc use the -pipe option by default?

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

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_

Re: This configure.in script does not work with autoconf 2.14

| 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), [ |

Re: Should gcc use the -pipe option by default?

On Mon, 3 Jul 2000, Mo DeJong wrote: > > 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 writ

Re: AC_F77_NAME_MANGLING question

On 3-Jul-2000, Akim Demaille <[EMAIL PROTECTED]> wrote: | Below we have a question regarding AC_F77_NAME_MANGLING, which, I | think, you wrote. I don't think I wrote that, or any of the other f77 support for autoconf, though I believe that the f77 support for autoconf is based on the macros tha

Re: AC_F77_NAME_MANGLING question

> Thus, if a compiler normally adds no underscore, but adds one underscore > to symbol names containing one already, f77_underscore will have the > wrong value "double" and AC_F77_WRAPPERS will produce incorrect code. You're right... The "right" behavior at this point would be to give an error

autoupdate test failure

I don't know anything about autoconf, but FYI, I just CVS updated autoconf and: = ./debug-99.sh: Testing autoupdate = ./tools.m4:180: testing... --- - Mon Jul 3 23:38:53 2000 +++ stdout Mon Jul 3 23:38:53 2000 @@ -1,6 +1 @@

Re: Should ./config.status --recheck rerun ./config.status?

On Jul 3, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > I think ./config.status --recheck should also regenerate the > Makefile from .in file. What do you think? Can't be done, in general. On MS-Windows, for example, you wouldn't be able to modify config.status while it's still open. That's wh

Re: Should gcc use the -pipe option by default?

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

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

Re: Should gcc use the -pipe option by default?

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 cha

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

Re: Should gcc use the -pipe option by default?

How about adding it to config.site if it's what you want by default on a particular machine? H

Is this the right way?

I want to make sure that two functions are available, and die if they're not. AC_CHECK_FUNC(seteuid, AC_DEFINE(HAVE_SETEUID, 1), AC_MSG_ERROR([This program re quires that seteuid be available])) AC_CHECK_FUNC(getpwent, AC_DEFINE(HAVE_GETPWENT, 1), AC_MSG_ERROR([This program requires that getpw