-----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-----
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
