Dear Eric,
Thanks for the quick response!
>> Was this a typo for mkstemp?
It's actually a typo for mkstemps. I'm attaching full generated conftest
(rconftest.c)
> Which version of autoconf generated this? I'm not finding anything
that
> matches the pattern above in autoconf 2.61; could you paste an actual
> configure snippet, or better yet, determine whether we are dealing
with
> AC_CHECK_FUNC or some other macro?
We have version 2.59 installed on our system. I'm assuming that's the
one which was used
to generate this. I can look around and see if we have later versions
installed somewhere else.
The configure snippet looks like:
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
choke me
#else
char (*f) () = $ac_func;
#endif
#ifdef __cplusplus
}
#endif
int
main ()
{
return f != $ac_func;
;
return 0;
}
It was derived from the aclocal.m4, which I have attached. Looks like
the function (is that what they are called in m4?) that is used to
generate this is called AC_LANG_FUNC_LINK_TRY.
>> configuring with one set of flags and compiling with another tends to
cause problems.
Apparently, so does the opposite! :-) Anyway, it would be nice to have
the choice, even if it isn't the default.
>> "(void *)(-1) != mktemps" is invalid if mktemps was declared as a
>> function, since it compares a void* with a function pointer, so there
is
>> likely a compiler out there that will fail to compile it.
Sorry, that was another typo. The test program I really meant to
suggest was:
int
main ()
{
return (void*)(-1) != (void*) mkstemps;
;
return 0;
}
I've attached a full text version rconftest1.c. It compiles and works on
at least with the Intel and gcc compilers.
>> For that matter, this may be relevant, from the ChangeLog:
>> 2005-10-19 Paul Eggert <eggert@xxxxxxxxxxx>
>> (AC_LANG_FUNC_LINK_TRY(C)): Call the function rather than simply
>> comparing its address. Intel's interprocedural optimization was
>> outsmarting the old heuristic. Problem reported by
>> Mikulas Patocka.
>>
>> In other words, if you run 'autoreconf -f' on the problem package so
that
>>it picks up a newer autoconf version, this problem should be fixed for
you.
This looks what I need to try. Many thanks to the pointer to this!
-- Robert
-----Original Message-----
From: Eric Blake [mailto:ebb9@xxxxxxx]
Sent: Saturday, September 29, 2007 5:42 AM
To: Cox, Robert
Cc: autoconf@xxxxxxx
Subject: Re: Question about autoconfig configure tests and
interprocedural optimization
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Cox, Robert on 9/28/2007 5:38 PM:
> Hello list members,
Hello, Robert,
> existence of mkstemps() on our system looks like:
>
> // Lots of headers and includes
>
> char (*f) () = mktemps;
Was this a typo for mkstemp?
>
> int
> main()
> {
> return f != mktemps;
> ;
> return 0;
> }
Which version of autoconf generated this? I'm not finding anything that
matches the pattern above in autoconf 2.61; could you paste an actual
configure snippet, or better yet, determine whether we are dealing with
AC_CHECK_FUNC or some other macro?
>
> The intent of such a test is to fail with an unresolved reference to
> mktemps if mktemps is not available. This works OK with the Intel
> compiler as long as we do not compile it with -ipo, but when we do,
the
> compiler notices that the "f != mktemps" is always false and
simplifies
> the program to
>
> main()
> {
> return 0;
> }
Yes, we were afraid that would happen someday. It's always a risk that
as
compilers get smarter, test programs have to get more creative to force
the compiler to do something to ensure linkage.
>
> (1) Is there anyway to specify that these conftests actually get
> compiled with a different optimization level (like -O0), rather than
> with the flags (CFLAGS, CXXFLAGS, LDFLAGS) that are passed to build
the
> application?
Not generally, since changing compiler flags can also change what works
and what doesn't work - in other words, configuring with one set of
flags
and compiling with another tends to cause problems.
>
> (2) What are the chances we could get the "f != mktemps" test
> replaced by something like "(void *)(-1) != mktemps" which would not
get
> optimized away at -ipo? (We also considered asking for "0 !=
mktemps",
> but worried that we might be able to optimize this away as well, if
not
> today, at some time in the future. Does someone have a suggestion for
a
> better test?
We need to also test that whatever approach works for intal also works
with gcc, and a few other compilers. Or maybe even go with both tests.
"(void *)(-1) != mktemps" is invalid if mktemps was declared as a
function, since it compares a void* with a function pointer, so there is
likely a compiler out there that will fail to compile it.
For that matter, this may be relevant, from the ChangeLog:
2005-10-19 Paul Eggert <eggert@xxxxxxxxxxx>
(AC_LANG_FUNC_LINK_TRY(C)): Call the function rather than simply
comparing its address. Intel's interprocedural optimization was
outsmarting the old heuristic. Problem reported by
Mikulas Patocka.
In other words, if you run 'autoreconf -f' on the problem package so
that
it picks up a newer autoconf version, this problem should be fixed for
you.
>
> (3) Is there a known, relatively painless (having to run sed on on
> the resulting config file or come up with literal assignments for the
> test results for every one of the system function tests NOT relatively
> painless) workaround for this issue?
For this particular problem, retooling broken packages with a newer
autoconf is probably the easiest approach.
>
> (4) Can we specify a different compiler for the conftests (like
> Microsoft Visual Studio or GCC) than we do for the application build
> (Intel compiler)?
Even worse - you really want to configure with the SAME compiler
(including options) as you will be compiling with.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@xxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG/kgm84KuGfSFAYARAom4AKCR6xvGKbxTP3i2mcuEu7pq1NTTFACgoSGN
OObw0j0+AiJ1tBA6N6zYm9E=
=KZnJ
-----END PGP SIGNATURE-----
Attachment:
rconftest.c
Description: rconftest.c
Attachment:
aclocal.m4
Description: aclocal.m4
Attachment:
rconftest1.c
Description: rconftest1.c
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
