On 2014.02.06 at 17:30 +0100, Thomas Jahns wrote:
> On 02/06/14 16:48, Markus Trippelsdorf wrote:
> > When using gcc with Link Time Optimization (-flto) enabled there are
> > certain configuration tests that always fail. For example the following
> > test taken from Firefox's configure.in:
> > ac_cv_visibility_default=no
> > if ${CC-cc} -fvisibility=hidden -Werror -S conftest.c -o conftest.s >/dev/null 2>&1; then
> > if ! egrep '\.(hidden|private_extern).*foo' conftest.s >/dev/null; then
> > ac_cv_visibility_default=yes
> > ...
> > which greps the assembler output, will not succeed with -flto (because
> > it produces GIMPLE output in special sections).
>
> this is broken on so many levels: 1. it totally relies on gcc which is a nice,
> if not the nicest, compiler but the scope of autotools is a bit broader, 2. it
> relies on the compiler being able to produce assembly equivalents which is
> probably possible for any compiler but very far from portable 3. it relies on
> the assembly following a particular symbol convention which is probably far from
> universal. With cases like this I propose to ask what the intended purpose was
> in the first place and look for a saner approach. I can see that JIT software
> has special needs but I can see no good way to approach this in a framework
> aimed at virtualizing build environments.
Unfortunately the idiom above is quite common for visibility=hidden
testing.
> > Now my question is if it wouldn't be desirable to have autoconf pass the
> > -fno-lto flag automatically by default (instead of requiring each
> > project to add it by hand when needed)?
>
> I'm very much opposed to autoconf adding arbitrary compiler flags, especially
> those which remove desirable features. Doing so "only" intermediately means the
> configure tests essentially run with another environment putting their validity
> unnecessarily into question.
Please note that the "environment" should be exactly the same for -flto
and -fno-lto. All features that pass configure tests with -fno-lto are
also available with -flto. Thus passing -fno-lto intermediately should
have no unexpected side effects.
> My recommendation would be to put some mechanism into your configure.ac that
> substitutes/adds to CFLAGS after the configure tests and before AC_OUTPUT and
> which is controlled solely by the users. I have this in several of my projects
> because profiling/tracing tools frequently must be used as compiler wrappers but
> are not up to pass the tests or need extra flags that cannot be used in the tests.
While that would work, it obviously requires manual intervention.
The issue will become urgent when gcc-4.9 gets released, because it
switched from "fat" LTO objects (that contain GIMPLE and the normal
object code) to "slim" LTO objects that only consists of the
intermediate internal representation (GIMPLE).
--
Markus
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
