On 09.02.2012, at 20:18, Paul Brook wrote: >>> On ARM Linux glibc provides a makecontext() that always fails ENOSYS, >>> so our configure test thinks there is makecontext support but when we >>> try to use it for coroutines it will fail and we abort. >>> >>> I have a workaround in qemu-linaro that just forces the makecontext >>> test to fail on ARM but I don't like that much. It would be better >>> to either drop our requirement for makecontext (Paolo had some patches >>> to try to do this IIRC) or to handle it failing at runtime. >> >> Or make the configure test be an execution test and always disable it for >> cross-compile? > > I'd rather not. If at all possible we should avoid runtime tests. Even for > "native" systems they generally give the wrong answer as the machine you're > building on often isn't the one you will be running on. If we know arm hosts > are broken then that's what we should test for in configure (with a comment > saying why). > > IMO consistency between builds for the same target environment is more > important than opportunistically probing in a native builds.
I agree for CPU features, sure. Anything that would be influenced by your build system vs execution environment. But in this case we're probing for a feature of a library we're linking against, so runtime checks really aren't all that bad, since you usually want to build against the same libc that you're executing against later on. Alex
