[MacPorts] #44627: ceres-solver @1.9.0 library segfaults

[MacPorts]

#44627: ceres-solver @1.9.0 library segfaults
------------------------------+--------------------------------
 Reporter:  julian.panetta@…  |      Owner:  macports-tickets@…
     Type:  defect            |     Status:  new
 Priority:  Normal            |  Milestone:
Component:  ports             |    Version:  2.3.1
 Keywords:  mavericks         |       Port:  ceres-solver
------------------------------+--------------------------------
 Installing Ceres through MacPorts and then compiling the following program
 with the built-in clang on Mac OS 10.9.{3,4} results in intermittent
 segfault/errors (it seems Ceres is scribbling over memory):

 http://julianpanetta.com/macports_bugs/test_ceres.cc

  {{{
 $ /usr/bin/clang++ -g -O0 -std=c++11 -I/opt/local/include
 -I/opt/local/include/eigen3 test_ceres.cc -L/opt/local/lib -lceres -lglog
 -lgflags -lcholmod -lcxsparse -framework accelerate -o broken
  $ ./broken
 0
 1
 [1]    75517 segmentation fault  ./broken
  $ ./broken
 0
 1
 2
 3
 libc++abi.dylib: terminating with uncaught exception of type
 std::length_error: vector
 [1]    75515 abort      ./broken
 }}}
 Sometimes the program runs to completion, but usually it segfaults in the
 ceres::Solve call. The std::length_error shown above is much more rare
 (happens because vectors v1s and v2s are getting scribbled over). This was
 a very difficult bug to track down, and unfortunately I haven't been able
 to simplify the test case further. I am filing the bug here rather than
 upstream because the following setups do not exhibit the problem, leading
 me to suspect the error is in the MacPorts build:

 1) Building ceres-solver manually (both from git repo, and from "latest
 stable release" link at ceres-solver.org), compiling test_ceres.cc with
 /usr/bin/clang;[[BR]]
 2) Compiling test_ceres.cc with clang-mp-3.{4,5}, linking against MacPorts
 libceres.a

 Those  made me suspect an ABI incompatibility with the MacPorts binary,
 but strangely...
 * Doesn't work: Installing ceres-solver from source MacPorts (using the -s
 option), compiling test_ceres.cc with /usr/bin/clang
 * Works: Building ceres-solver manually using /usr/bin/clang, compiling
 test_ceres.cc with macports clang 3.{4,5}
 * Works: Building ceres-solver manually using clang-mp-3.4, compiling
 test_ceres.cc with /usr/bin/clang
 * Fails to link: Building ceres-solver manually using clang-mp-3.5,
 compiling test_ceres.cc with with any compiler (including clang-mp-3.5!)

 In summary, manually building ceres-solver using cmake works in all cases
 I tested regardless of compiler (except the link failure case), while
 installing through MacPorts (from either binary or source) only works with
 clang-mp-3.{4,5} and not /usr/bin/clang. To me this suggests there's
 something wrong with how MacPorts configures ceres-solver, but if we
 decide that the bug lies upstream I'm happy to report the issue at
 https://code.google.com/p/ceres-solver/issues/list

 For reference, my "built-in" clang is:
  $ clang++ --version
 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
 Target: x86_64-apple-darwin13.2.0
 Thread model: posix

-- 
Ticket URL: <https://trac.macports.org/ticket/44627>
MacPorts <http://www.macports.org/>
Ports system for OS X