Hey guys, while working on the gradle native support I've noticed some issues with incremental builds.
I've added an implementation of the AbstractLanguageIncrementalBuildIntegrationTest For ObjectiveC and Objective-CPP, which works without problems with gcc and with clang on osx, but I noticed randomly failing tests when using clang on ubuntu. After some digging I noticed that the generated object files can differ, even when created from exactly the same sources/flags. When comparing the according assembler code, I see that the address space is chosen randomly (see. diff here: http://pastebin.com/uY1LERGX). This behavior comes from a security feature called ASLR (Address space layout randomization). Toget our tests to pass on every invocation, I needed to disable ASLR by globally configuring it through /proc/sys/kernel/randomize_va_space (0 for disabling, 2 for enabling, 1 for "conservative randomization) or by disabling it locally via "> setarch `uname -m` -R /bin/bash". So, ASLR breaks our incremental builds because the generated object files can differ. I havn't yet figured out why ASLR currently does not affect our c / c++ integration tests with clang. There are also a bunch of raised bugs that prevents/prevented llvm to be complete deterministic. Some of them were already solved in newer llvm versions. To get the incremental build running we would need to be able to disable ASLR in our native toolchains. Of course this comes with the cost of less secure output that ASLR introduced. I see 3 options at the moment: - don't deal with ASLR at all with the cost of possibly loosing incremental build support. - always disable ASLR if possible to have deterministic builds (with the cost of loosing ASLR introduced security). - model this in our toolchains to allow enabling/disabling ASLR support. Thoughts? --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email