Closed tkelman closed 8 years ago
Done, I agree with you, hunting down every dependency that mishandles environment-set CFLAGS
is a big pain.
Pretty much all of our build environments inject CFLAGS
, it's just that the Debian and Homebrew devs are smarter than I and inject them not through environment variables (for the exact reason that many packages don't handle them properly) and instead inject them at a lower level; Debian does so by requiring packages to change their Makefile to call $(dpkg-buildflags --get CFLAGS)
, whereas Homebrew creates wrapper scripts for cc
, c++
, etc... and injects the necessary parameters in there via their superenv
system.
Thanks! Were they setting anything that was necessary, or was it all for convenience's sake? Aside from the few flags we set here for portable binaries, I think we wouldn't want anything to be different between a default make
from source and what our binaries provide from the buildbots, right? Distros have various optimization, hardening, and split-debug-info build standards they set, and I guess homebrew does things with the apple toolchain specifying the osx version. I feel like we'd more highly value build predictability than those kind of standards?
They were setting things like -I~/local/include
, which may or may not be important on the old linux buildbots, because that's where gcc5 lives (which we build from source). We should perhaps check that FFTW isn't unnecessarily slow using the generic linux binaries either (although we manually set an march
that's pretty conservative on those)
Did you modify the mac buildbot, the linux ones, or everything? Just in case it all breaks and we need to put it back and find a gradual fix...
I've manually commented out the lines that set CFLAGS
and LDFLAGS
in the bashscripts on the osx10.9
builder. Those files are in a git repo that will try to auto-update and fail because of this modification; that's probably fine for the time being. Although I think we should try to fix the FFTW build process to allow for use-set CFLAGS
, there are an awful lot of things I think we should fix that aren't going to get fixed any time soon. ;)
I don't want to disable the CFLAGS
stuff on all the buildbots right now because I'm afraid it will break the ancient linux builders. Perhaps what we should do instead is manually set CFLAGS=""
if we're on an OSX builder in inventory.py
, similarly to how we override CXXFLAGS
here. That way crazy bash scripts won't hurt us anymore, and this knowledge is a little more centralized.
Though I wonder whether that CXXFLAGS is causing the same issue for llvm etc?
We could check via the same test that sgj posted in the other thread for fftw, right?
If we have a C++ library that records its optimization level?
Oh, does FFTW
not care about CXXFLAGS
? Is LLVM the only one that cares about its CXXFLAGS
? If so, we can just nuke a centos5.11
builder, then rebuild julia and look at the output to see if the g++
invocations have optimization flags in them.
I don't know whether or not FFTW has any C++ in it. LLVM absolutely does, SuiteSparse has some, openspecfun (faddeeva) has a little
I nuked the centos5.11-x64
builder, and am running a manual build on it. The relevant logfile shows llvm 3.7.1 being built with -O3
. An example gcc
invocation:
/home/centos/local/bin/gcc -m64 -DCLAR_FIXTURE_PATH=\"/home/centos/buildbot/slave/package_tarball64/build/deps/srccache/libgit2-211e117a0590583a720c53172406f34186c543bd/tests/resources/\" -DCLAR_RESOURCES=\"\" -DCLAR_TMPDIR=\"libgit2_tests\" -DGIT_ARCH_64 -DGIT_CURL -DGIT_OPENSSL -DGIT_SSH -DGIT_SSH_MEMORY_CREDENTIALS -DGIT_THREADS -DGIT_USE_STAT_MTIM -DOPENSSL_SHA1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Wall -Wextra -I/home/centos/local/include -fvisibility=hidden -fPIC -Wno-missing-field-initializers -Wstrict-aliasing=2 -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-function -O3 -DNDEBUG -I/home/centos/buildbot/slave/package_tarball64/build/deps/srccache/libgit2-211e117a0590583a720c53172406f34186c543bd/src -I/home/centos/buildbot/slave/package_tarball64/build/deps/srccache/libgit2-211e117a0590583a720c53172406f34186c543bd/include -I/home/centos/buildbot/slave/package_tarball64/build/usr/include -I/home/centos/buildbot/slave/package_tarball64/build/deps/srccache/libgit2-211e117a0590583a720c53172406f34186c543bd/deps/http-parser -I/home/centos/buildbot/slave/package_tarball64/build/deps/srccache/libgit2-211e117a0590583a720c53172406f34186c543bd/tests -o CMakeFiles/libgit2_clar.dir/src/signature.c.o -c /home/centos/buildbot/slave/package_tarball64/build/deps/srccache/libgit2-211e117a0590583a720c53172406f34186c543bd/src/signature.c
@staticfloat
These are overwriting CFLAGS resulting in slower performance in a bunch of dependency libraries. It happened in openlibm and it's happening for FFTW too, ref https://github.com/JuliaLang/julia/issues/17000#issuecomment-241909841.
The point of a buildbot is to be a clean reproducible environment for a standard build. If all this customization is needed for homebrew bottle building, it should be isolated to the homebrew jobs, and reflected in the buildbot configuration files here rather than in the VM customization / provisioning which I still have very little visibility to.