Cross-platform "warning is an error" with Autoconf?

[Jeffrey Walton]

I'm having trouble crafting an Autotools test. I'm trying to test for
the availability of Micrsoft's init_seg():

## This needs to be cross-platform, and not MSC specific
CXXFLAGS="/WX"
XXX_PROGRAM="#include <string>
struct Bar {
Bar(int x) : m_x(x) {}
Bar(const Bar& o) : m_x(o.m_x) {}
Bar& operator=(const Bar& o) {m_x=o.m_x; return *this;}
static int s_x;
int m_x;
};
#pragma init_seg(".CRT$XCU")
int Bar::s_x = -1;
// This should be in a separate source file violating init order.
// The problem is, we don't know how to do it with Autotools.
Bar f = Bar::s_x;"

The problem is, Clang, GCC, XLC, SunCC, etc issue a warning for an
unknown pragma. Detecting the warning is part of the test we need.

If I change to CXXFLAGS="-Werror" then MSC and other Windows compilers
incorrectly reject the program.

I think the root cause of the problem is, I need a cross-platform way
to say "treat warnings as error". But I don't see an
AC_WARNINGS_AS_ERRORS or similar in Autoconf.

How do I tell Autoconf to treat warnings as errors in a cross-platform way?

Jeff

[Peter Johansson]

Hi Jeff,

Post by Jeffrey Walton
I'm having trouble crafting an Autotools test. I'm trying to test for
## This needs to be cross-platform, and not MSC specific
CXXFLAGS="/WX"
XXX_PROGRAM="#include <string>
struct Bar {
Bar(int x) : m_x(x) {}
Bar(const Bar& o) : m_x(o.m_x) {}
Bar& operator=(const Bar& o) {m_x=o.m_x; return *this;}
static int s_x;
int m_x;
};
#pragma init_seg(".CRT$XCU")
int Bar::s_x = -1;
// This should be in a separate source file violating init order.
// The problem is, we don't know how to do it with Autotools.
Bar f = Bar::s_x;"
The problem is, Clang, GCC, XLC, SunCC, etc issue a warning for an
unknown pragma. Detecting the warning is part of the test we need.
If I change to CXXFLAGS="-Werror" then MSC and other Windows compilers
incorrectly reject the program.
I think the root cause of the problem is, I need a cross-platform way
to say "treat warnings as error". But I don't see an
AC_WARNINGS_AS_ERRORS or similar in Autoconf.

There is an AC_LANG_WERROR, but not sure how cross-platform it is.
Hopefully it parses stderror rather relying on compiler switches such as
-Werror. IIRC, it worked for me when I used it, but I think one problem
was that there was no way to turn off this "warnings are errors"-behaviour.

Cheers,
Peter

[Nick Bowler]

Post by Peter Johansson

Post by Jeffrey Walton
If I change to CXXFLAGS="-Werror" then MSC and other Windows compilers
incorrectly reject the program.
I think the root cause of the problem is, I need a cross-platform way
to say "treat warnings as error". But I don't see an
AC_WARNINGS_AS_ERRORS or similar in Autoconf.

There is an AC_LANG_WERROR, but not sure how cross-platform it is.
Hopefully it parses stderror rather relying on compiler switches such as
-Werror. IIRC, it worked for me when I used it, but I think one problem
was that there was no way to turn off this "warnings are errors"-behaviour.

It appears to work simply by checking whether or not the compiler produced
any output whatsoever on standard error.

There appears to be no documented way to turn it off after you turn it on.
This is probably an oversight, because several of Autoconf's own tests do
exactly that with a pattern like:

save_ac_FOO_werror_flag=$ac_FOO_werror_flag
ac_FOO_werror_flag=yes
[perform tests here]
ac_FOO_werror_flag=$save_ac_FOO_werror_flag

where FOO is the language name; e.g. "cxx" for C++. Being able to save
and restore the state in a similar manner would probably more useful
than the one-way switch we have today. Anyway, if ac_cxx_werror_flag
is set to any nonempty string then the standard error check is enabled
for C++ compiles, but this isn't documented behaviour so up to you
whether you want to make use of that or not.

You could also submit a patch which gives a documented way to do this :)

Cheers,
Nick

[Paul Eggert]

Post by Nick Bowler
There appears to be no documented way to turn it off after you turn it on.
This is probably an oversight

I vaguely recall that it was not an oversight, and that we ran into trouble in
thinking about how such a feature would work. Sorry, don't remember the details.