CI support

[Keno]

LLVM has nightly APTs which might help.

[Keno]

@staticfloat Do you suppose you could get me nightlies with julia in Cxx configuration?

[staticfloat]

I daresay I could. What platforms would you want?

[Keno]

Ubuntu would be a great start, so I can get travis up.

[staticfloat]

It will probably be easier for me to get you them in .tar.gz format as opposed to .deb format. Seeing as that's what we use on Travis for nightlies anyway, will that be a problem? (The travis code snippet is showing that we just download a .tar.gz from status.julialang.org, unzip it and run with it)

[Keno]

No, that should be fine.

[tkelman]

We already have the nightly llvm-svn test builds, all it costs is some S3 space to also package them up and upload them. Just make sure that a failure to compile against llvm svn doesn't prevent the nominal-llvm-version nightlies from building :)

[staticfloat]

@Keno looks like the LLVM-svn build is failing due to Python 2.6.8 as opposed to 2.7..... is that normal? Even though I've defined LLDB_DISABLE_PYTHON=1?

[tkelman]

I saw some messages to that effect on llvmdev not that long ago, they have bumped the minimum requirement for building LLVM itself to 2.7. The LLDB flag has more to do with whether python is embedded into the debugger I think, but LLVM still needs Python to build its test suite. I believe the intent of increasing the minimum to 2.7 is to make their life a little easier to eventually port the test suite bits to be Python 3-compatible. Can we get 2.7 from devtoolset maybe?

edit: or just build it since it's only needed for building LLVM, we're already building GCC after all.

[staticfloat]

Can we get 2.7 from devtoolset maybe?

Nope, but we can build it. :P

EDIT: Aaaand, we are on the same wavelength.

[staticfloat]

Built Python 2.7, now we're getting this error log. It's long, but toward the bottom we get:

cp: cannot stat `/home/centos/buildbot/slave/package_cxx32/build/deps/llvm-svn/build_Release+Asserts/tools/clang/runtime/compiler-rt/clang_linux/builtins-i386/libcompiler_rt.a': No such file or directory
make[8]: *** [/home/centos/buildbot/slave/package_cxx32/build/deps/llvm-svn/build_Release+Asserts/Release+Asserts/lib/clang/3.7.0/lib/linux/libclang_rt.builtins-i386.a] Error 1

Any thoughts? The build process is here, with the important bits being:

LLVM_VER=svn
LLVM_ASSERTIONS=1
BUILD_LLVM_CLANG=1
BUILD_LLDB=1
USE_LLVM_SHLIB=1
LLDB_DISABLE_PYTHON=1

[tkelman]

I'm not sure what changed upstream relative to previous versions of LLVM (or why we haven't seen this earlier), but I suspect on 32 bit builds it needs http://compiler-rt.llvm.org/ to be put in the right place for some of the compiler intrinsics to work. We should probably expand deps/Makefile to add a BUILD_COMPILER_RT and BUILD_LLD options at some point.

If the 64 bit build worked, maybe start with that? Running Travis on a 32-bit build of Julia can't be done all that elegantly right now anyway.

[staticfloat]

I thought this happened on both 32 and 64-bit, but it turns out I'm running into a different error on 64-bit:

/home/centos/buildbot/slave/package_cxx64/build/deps/llvm-svn/tools/lldb/source/Host/common/File.cpp: In member function ‘lldb_private::Error lldb_private::File::Open(const char*, uint32_t, uint32_t)’:
/home/centos/buildbot/slave/package_cxx64/build/deps/llvm-svn/tools/lldb/source/Host/common/File.cpp:292:18: error: ‘O_CLOEXEC’ was not declared in this scope
         oflag |= O_CLOEXEC;
                  ^
make[9]: *** [/home/centos/buildbot/slave/package_cxx64/build/deps/llvm-svn/build_Release+Asserts/tools/lldb/source/Host/common/Release+Asserts/File.o] Error 1

[tkelman]

The 64 bit issue would appear to be since RHEL 5's kernel version predates the O_CLOEXEC flag - http://man7.org/linux/man-pages/man2/open.2.html says "since Linux 2.6.23," https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_5 says it's using 2.6.18. This should maybe be reported upstream to the LLDB folks, RHEL5 is old but still theoretically supported until 2017 ("extended lifecycle" to 2020). Looking at http://lists.qt-project.org/pipermail/interest/2012-December/004907.html we might just try building with -DO_CLOEXEC=0 and see if that works.

[staticfloat]

Thanks for tracking that down, Tony. Just BTW, it looks like the nightly 32-bit LLVM-svn builder is running into the compiler_rt issue as well. Configuration changes here, buildbot job running here.

[tkelman]

Maybe upstream changed something in the build system. It looks like we currently are (should be) building compiler-rt when BUILD_LLVM_CLANG or however that's spelled is set, which Cxx does.

[staticfloat]

@Keno Looking through the LLVM source code, it looks like compiler-rt is explicitly removed from the make targets, so we're supposed to do something special to get it to compile:

$ grep compiler-rt deps/llvm-svn/build_Release+Asserts/projects/Makefile
# Don't build compiler-rt, it isn't designed to be built directly.
DIRS := $(filter-out compiler-rt,$(DIRS))

[tkelman]

The -DO_CLOEXEC=0 flag apparently isn't making it to the lldb build http://buildbot.e.ip.saba.us:8010/builders/package_cxx64/builds/98/steps/make%20binary-dist/logs/stdio

[staticfloat]

I'm trying putting it into CPPFLAGS, as opposed to DEPS_CXXFLAGS.

[tkelman]

I'm going to guess that lldb is just not set up correctly wrt build flags when you use autotools to build llvm.

[staticfloat]

Welp, the new stuff worked, but now we get this;

.../tools/lldb/source/Host/posix/FileSystem.cpp:21:25: fatal error: linux/magic.h: No such file or directory compilation terminated.

I have the kernel-devel package installed, but it puts magic.h at /usr/include/, not /usr/include/linux. Furthermore, the symbols it's trying to pull in (CIFS_MAGIC_NUMBER and friends) aren't defined in this version of magic.h. I'm of the opinion that lldb just doesn't support CentOS 5, so I'm going to try switching it over to being built on Ubuntu 12.04.

[tkelman]

The selected GCC C++ compiler is not new enough to build LLVM. Please upgrade to GCC 4.7

[staticfloat]

Yep, workin' on it. :)

[staticfloat]

I have to figure out why ld built from my binutils is complaining about not having a sysroot, whatever that is.

[tkelman]

@staticfloat I don't think we want a source build of gcc 5.1.0 to be used on the non-cxx ubuntu 12.04 builders, do we? http://buildbot.e.ip.saba.us:8010/builders/build_ubuntu12.04-x64/builds/1994/steps/shell_1/logs/stdio

[staticfloat]

Whether we want it or not, gcc-5.1.0 isn't working like we want it to, so I'm removing it until I can get it working properly. Looks like I might need to build glibc to get pthreads working.

[tkelman]

We haven't had nightlies for 6 days, and given that package precompilation was just merged and a release candidate will probably be tagged soonish, I think it's more important to get the buildbots back in regular working order and revisit Cxx nightlies after 0.4.0 is out.

[staticfloat]

I'm coming back at this again, now that I've worked through the rest of my buildbot maintenance backlog. :) I'm going to try building these guys on the CentOS 5 builders again now that I've built Python 2.7 on them.

[staticfloat]

Currently trying on CentOS 6

[staticfloat]

binutils 2.25, GCC 5.1 and git 2.5.3 all custom-built in order to get a solid build environment. Build ongoing, let's see how it shakes out.

[staticfloat]

Nope, looks like we need python too. :)

[staticfloat]

Python 2.7.10 built and running. The show goes on.

[staticfloat]

Ran into a glibc problem where the new GCC I'm using (5.1) used a super-new version of glibc while building LLVM, which failed when it tried to run llvm-tblgen since it used the host system's libstdc++, which was obviously incompatible. I've since set LD_LIBRARY_PATH such that the new GCC's libraries are being used first, if this compiles all the way, I'll ensure that the correct libraries get bundled up with make binary-dist and we'll see if this is as portable as we hope! The show goes on.

[staticfloat]

So I got it working once. That archive works, except that it doesn't bundle libedit.so.0, which is a problem. I tried to fix that via this branch, but LLVM doesn't seem to find the header files that it needs, even though I know they are installed to $prefix/usr/include. Any ideas on how I can make the build process automatically hint to LLVM that it should search in the proper include directories? I suppose I could tack it onto CPPFLAGS, but I would have thought LLVM should be searching its own install prefix anyway.

[staticfloat]

It looks like (modulo LLVM-svn breakage) this builder has been succeeding every now and then. Just marking this down as "kinda-sorta-working" so that we know what the state of things are once we decide to pick this up again.

[Keno]

I'm planning to start supporting at least some version of 0.4 with some version of Cxx. After my backports go in, could we have binaries of 0.4.1 (whenver that comes out) that include everything necessary to get Cxx running.

[staticfloat]

Yep, we'll make sure of it.

[Keno]

Can we switch the buildbot to the kf/gallium LLVM branches, or at least have one that does, so we can track regressions in julia that cause Cxx.jl to fail?

[tkelman]

I think we can tweak that here: https://github.com/staticfloat/julia-buildbot/blob/17b09b1043f7d634737c018b8d1ba9a0e9b855b1/master/nightly_cxx.py#L44

[staticfloat]

Is there a make variable that I can set to check out a particular branch?

[Keno]

override LLVM_GIT_URL_LLVM=https://github.com/JuliaLang/llvm.git
override LLVM_GIT_URL_LLDB=https://github.com/JuliaLang/lldb.git
override LLVM_GIT_URL_CLANG=https://github.com/JuliaLang/clang.git
override LLVM_GIT_VER=kf/gallium
override LLVM_GIT_VER_LLDB=kf/gallium
override LLVM_GIT_VER_CLANG=kf/gallium

[staticfloat]

JuliaCI/julia-buildbot@07473b2

[Keno]

Thanks!

[staticfloat]

I've forced a build to ensure that I don't have a syntax error or something.

[staticfloat]

Welp, that didn't take long;

/home/centos/buildbot/slave/nightly_cxx64/build/deps/jldownload /home/centos/buildbot/slave/nightly_cxx64/build/deps/srccache/llvm-kf/gallium.src.tar.xz http://llvm.org/releases/kf/gallium/gallium.src.tar.xz

[staticfloat]

I need to tell the Makefiles that LLVM should be downloaded over git, right?

[Keno]

LLVM_VER should still be svn

[Keno]

LLVM_GIT_VER is for the branch

[Keno]

Also, the git repository is pretty big (1.5ish GB), maybe we should add the option to make a shallow checkout?

[tkelman]

there are some complaints about https://github.com/JuliaLang/lldb/blob/kf/gallium/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp, see http://buildbot.e.ip.saba.us:8010/builders/nightly_cxx64/builds/71/steps/make%20binary-dist/logs/stdio

Any chance that has been fixed upstream?

[tkelman]

was fixed upstream, llvm-mirror/lldb@b49efe0 needs to be cherry-picked or rebased in to your lldb branch

[tkelman]

Bump, you need to fix lldb so it builds with gcc 5, your last rebase was at a broken point in the upstream history.

[Keno]

Travis is setup now.