Changes between Initial Version and Version 1 of Ticket #44627
- Timestamp:
- Aug 13, 2014, 9:18:46 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #44627
- Property Cc mmoll@… removed
- Property Owner changed from macports-tickets@… to mmoll@…
-
Ticket #44627 – Description
initial v1 3 3 http://julianpanetta.com/macports_bugs/test_ceres.cc 4 4 5 5 {{{ 6 6 $ /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 7 7 $ ./broken … … 19 19 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: 20 20 21 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]] 22 2)Compiling test_ceres.cc with clang-mp-3.{4,5}, linking against MacPorts libceres.a21 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; 22 2. Compiling test_ceres.cc with clang-mp-3.{4,5}, linking against MacPorts libceres.a 23 23 24 24 Those made me suspect an ABI incompatibility with the MacPorts binary, but strangely... … … 31 31 32 32 For reference, my "built-in" clang is: 33 {{{ 33 34 $ clang++ --version 34 35 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) 35 36 Target: x86_64-apple-darwin13.2.0 36 37 Thread model: posix 38 }}}