OSX/clang compatibility broken by "mutation keys return pair of key/count in sampler, to aid downstream filtering" about fwdpp HOT 19 CLOSED

This is another clang issue specific to OS X that doesn't replicate elsewhere. I'll "fix" this, but what is happening here on OS X is wrong. Clang 3.6 through 3.9 on Linux all do the right thing.

I've deleted the 0.5.4 tag for right now, too, and will re-release when this is fixed.

from fwdpp.

Thanks. It would be a shame to have to set ENV.libstdcxx since we've been trying to get rid of all of those. Right now it's down to 7 formulae out of 4,300 in Homebrew Core and Homebrew Science combined.

from fwdpp.

This is fixed. Curiously, the libstdcxx apparently was generating the correct code (I did not test that myself, though). I also changed the title to reflect what was actually happening--the c++11 was fine, actually.

from fwdpp.

@molpopgen by the way, it's not about the compiler itself. GCC-6 will fail in the same way on the old code:

/usr/local/bin/g++-6  -w -pipe -march=core2 -msse4 -mmacosx-version-min=10.11 -O2  -L/usr/local/lib -F/usr/local/Frameworks -Wl,-headerpad_max_install_names -o diploid_ind diploid_ind.o  -lgsl -lgslcblas -lz  -lsequence
Undefined symbols for architecture x86_64:
  "Sequence::PolyTable::assign(__gnu_cxx::__normal_iterator<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const*, std::vector<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >, __gnu_cxx::__normal_iterator<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const*, std::vector<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >)", referenced from:
      _main in diploid_ind.o
  "Sequence::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Sequence::PolyTable const&)", referenced from:
      _main in diploid_ind.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [diploid_ind] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

from fwdpp.

from fwdpp.

Right, the point being it's a macOS thing, not an Apple's-clang thing.

from fwdpp.

@molpopgen unfortunately although your fix got it working with clang, it's broken with GCC:

/usr/local/bin/g++-6  -w -pipe -march=core2 -msse4 -mmacosx-version-min=10.11 -O2  -L/usr/local/lib -F/usr/local/Frameworks -Wl,-headerpad_max_install_names -o diploid_ind diploid_ind.o  -lgsl -lgslcblas -lz  -lsequence
Undefined symbols for architecture x86_64:
  "Sequence::PolyTable::assign(__gnu_cxx::__normal_iterator<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const*, std::vector<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >, __gnu_cxx::__normal_iterator<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const*, std::vector<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >)", referenced from:
      _main in diploid_ind.o
  "Sequence::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Sequence::PolyTable const&)", referenced from:
      _main in diploid_ind.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [diploid_ind] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

from fwdpp.

So this is not the same issue. Here, you are having trouble linking the example programs to libsequence, which is only a dependency for building the examples. (./configure checks for its presence, and will not build examples if not there.) I am guessing you have libseqeuence installed and compiled using clang, but are attempting to link object code generated using gcc-6. That combo is not guaranteed to work due to ABI issues.

from fwdpp.

On El Capitan with homebrew gcc-6, and libsequence/master (same as 1.9.0) compiled & installed using brew/gcc6, everything compiles and all unit tests pass. So your latest issue is a toolchain problem, not a fwdpp problem.

I can recreate what you posted in the "reverse" direction, too. Install lib sequence with gcc-6, then attempt to compile fwdpp examples with Xcode clang. I get the same missing symbols.

from fwdpp.

Yup, that fixed it, thanks. It seems I also needed to re-build boost with gcc. Did you need to too?

from fwdpp.

from fwdpp.

Nope, not moot.

We have several versions of gcc, and try to mark known failure cases with gcc with the fails_with DSL (which may be restricted to certain versions of gcc or macOS).

By default anything with a fails_with clang (which may be restricted to specific versions of clang or macOS), will attempt to use gcc or prompt the user to install gcc if not already installed. If the latest version of gcc is also marked with a fails, then brew will attempt to use the next most recent version of gcc, and prompt the user to install it if not already installed, etc.

gcc is also the default way to satisfy some special requirements such as fortran and openmp. Recently, llvm 3.9 was added as a new way to satisfy the openmp requirement, and may eventually be the default way to satisfy it.

When gcc is used to build the binaries of a formula during bottling for whatever reason, and the binaries end up linked to libgcc, we will also try to add depends_on "gcc" explicitly to make sure gcc gets installed before CI tests the formula when it's a reverse dependency of something else that's being modified in a PR, and so that it can be revision bumped when the gcc libraries are version bumped.

In homebrew/science gcc is particularly relevant because everything in homebrew/science tries to be compatible with both macOS and Linux, and because the special requirements are more common.

That said, in the general case where gcc is not being used deliberately by brew, we only officially support clang in homebrew/core. Anything that cannot build with clang on the latest version of macOS is subject to boneyarding (being moved to homebrew/boneyard) at any time, and typically that will be determined based on whether upstream has expressed an intent to restore clang compatibility or not. If the clang breakage only occurs on versions of macOS that are not the current version, that is more likely to be tolerated with a longer term gcc dependency assuming it's the latest version of gcc.

Anyway, probably much more info than you wanted, but suffice it to say gcc is far from an academic concern, and is a rather popular formula.

from fwdpp.

from fwdpp.

The user will get a warning if there's a C++ standard mismatch, but no it's not recursively enforced up and down the dependency tree. With special requirements there will often be an option in the dependencies for the same requirement so we'll have like foo

depends_on :fortran => :optional
if build.with? "fortran"
  depends_on "bar" => "with-fortran"
else
  depends_on "bar"
end

and bar

depends_on :fortran => :optional

from fwdpp.

from fwdpp.

Truth be told, I tend to agree with you about this but at this point I think we're in the minority. It's not even possible in brew to do things like depends_on "bar" => "gcc6" if ENV.compiler == :gcc. That is possible with :cxx11 if the dependency has option :cxx11. The only thing we have currently that does enforcement up and down the tree is :universal for combo 32-bit/64-bit binaries.

from fwdpp.

@molpopgen if you want to open a PR for stricter C++ handling, here's how :universal is implemented: https://github.com/Homebrew/brew/search?utf8=✓&q=inherited_options+OR+inherited_options_for&type=Code

Also you could open a proposal if you don't want to implement it yourself here: https://github.com/Homebrew/brew-evolution

from fwdpp.

By the way when you re-publish the new version, you'll probably want to make it 0.5.5 or 0.5.4.1 since tags won't be updated when people git pull.

from fwdpp.

from fwdpp.