[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Don’t use AC_EGREP_CPP if affected by CFLAGS

From: Paul Eggert
Subject: Re: [PATCH] Don’t use AC_EGREP_CPP if affected by CFLAGS
Date: Mon, 6 Nov 2017 18:59:28 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

The approach you suggest would not work with cross-compilation, right? So it might be better to use the output of $CPP to generate a .c file that could be compiled and not run, that would check that the compiler options were consistent with the preprocessor options.

Probably we need to draw a line between
  - macros that often change the result of $CPP output
    (e.g. -D and -I options, but also -m32/-m64)
  - macros that rarely change the result of $CPP output because they are just
    witness macros of optimization options (e.g. __OPTIMIZE__).

In that case, the issue boils down to: what is the safe set of options that builders can put into CFLAGS instead of CPPFLAGS+LDFLAGS (or CC)? Clearly options like -D and -I are unsafe, and it seems we agree that -O and -fsanitize=address are safe. However, we disagree whether -m32 and -m64 are safe.

The list of safe options would be ad-hoc, whatever it is. For example, the following GCC options can all affect the preprocessor; which should be considered safe and why?

-pthread -ffast-math -fnext-runtime -fno-exceptions -fno-inline -fno-math-errno -fstack-protector -funsigned-char -mbig-endian -melf -mwin32 -pedantic -std

My impression is that builders mentally put options like these into CFLAGS and not CPPFLAGS because they think of them as compiler not preprocessor options. So I would consider all these options to be safe (along with -m32 and -m64 and -fsanitize). Presumably you would consider some to be safe and some unsafe, but what rule would you suggest to distinguish safe from unsafe options? Whatever the rule is, it should be simple and easy to remember.

The rule I am thinking of is, "If the option is clearly intended for the preprocessor, it's unsafe. Otherwise it's safe." So, for example, -D, -U, and -I are unsafe, whereas the options mentioned above are safe. This rule is simple and easy to remember. I realize it can lead to slower 'configure' scripts, but in practice they're not so much slower as to be worth the cost of error-prone configuration.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]