bottles for non-default options (e.g. boost/c++11 & llvm/clang)

[slayoo]

Hi,

I was trying to use the OSX infrastructure at travis-ci.org - an automated-build service for github projects. In short, what you get there on every build is a clean OSX install with homebrew and some popular packages + 1h of wall-clock time. The project I was trying to test there (github.com/igfuw/libmpdataxx) depends on C++11, Boost and it needs a more recent clang than the one installed by default through XCode there.

Trying to get a newer clang from homebrew, I realised it's not doable as the 1h time slot is not enought to compile llvm --with-clang and, if I understand correctly, since it is not the default option set, it does not ship in bottles.

Trying then to use g++ instead of clang, I came across the same problem as we need boost compiled with --c++11 and compilation of boost also timeouts the build there, and no c++11-boost bottle is available (IIUC).

Is there any chance to get boost-c++11 and llvm-clang in bottles?
Is there any way to workaround the above-described issues in another way?

Thanks,
Sylwester

[jacknagel]

On OS X 10.9 and 10.10, you can compile C++11 code against the default boost bottle.

For clang, I recommend using llvm35 from homebrew-versions, which has clang installed by default, and is bottled.

[slayoo]

Thanks for quick reply!

Re Boost, we have encountered exactly the same problem as described here:
http://stackoverflow.com/questions/19081937/gnuplot-iostream-example-does-not-compile-with-c11
and as reported there enabling c++11 for brewed boost helped on a local machine, that's why we were trying to do so at Travis as well.

I'll try llvm35 right away, thanks!
Sylwester

[jacknagel]

What compiler are you using to compile the software that is using boost?

The important thing is that both boost and the software linking to boost are both linked against the same C++ stdlib.

If boost is compiled with clang, this will be libc++ (the upshot being that the consuming software must also be compiled with clang).

If boost is compiled with GNU g++, this will be libstdc++ (the upshot being that the consuming sofware must also be compiled with g++).

[slayoo]

Thanks again for the reply.

Indeed, concerning boost it seems that it is the libc issue - using llvm there is no problem with boost.

But the clang++ from the llvm35 package has the same issues as the one from XCode (it seems to be a bug with treatment of volatile variables that is already fixed in what Ubuntu calls llvm 3.5~svn201651-1ubuntu1).

Is there any way of getting a bottle of clang newer than the one in the llvm35 package?

Thanks,
Sylwester

[MikeMcQuaid]

Is there any way of getting a bottle of clang newer than the one in the llvm35 package?

You'll need to build/host one yourself.

Passing on this as I'm not interested in supporting non-default bottles. I'd review a PR to add support for creating these bottles but I don't think we'll be hosting them. Sorry!