Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling Issue on Mac OSX 10.8 #23

Closed
smcgill3 opened this issue Apr 8, 2013 · 15 comments
Closed

Compiling Issue on Mac OSX 10.8 #23

smcgill3 opened this issue Apr 8, 2013 · 15 comments
Labels

Comments

@smcgill3
Copy link

smcgill3 commented Apr 8, 2013

Hello,

I downloaded your recent release of OctoMap - it looks great! I compiled and have a working example on my Linux Mint 64 bit machine. I am trying to port some code for use on my Mac. Following the simple installation method, I ran into difficulties.

mkdir build
cd build
cmake ..
This yields: http://pastebin.com/B6bgDUUu

make
This yields, in stderr: http://pastebin.com/wvGgyqxR
In stdout: http://pastebin.com/sS6HwXuC

I am not sure, but it may be related to clang:
http://clang.llvm.org/compatibility.html#cxx

Please let me know if you need anything else, or would like me to modify anything. Thanks a ton for your support.

Sincerely,
Steve McGill

@yida
Copy link

yida commented Apr 8, 2013

use c++ on osx 10.8 works fine without this problem
$ c++ -v
Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0

However, there is a problem with compare_octrees.cpp
/Users/Yida/Projects/octomap/octomap/src/compare_octrees.cpp:129:11: error: use of
undeclared identifier 'isnan'; did you mean 'std::isnan'?
if (isnan(kld)){
^~~~~
std::isnan
/usr/include/c++/4.2.1/cmath:550:5: note: 'std::isnan' declared here
isnan(_Tp __f) { return ::__gnu_cxx::__capture_isnan(__f); }
^

By adding using namespace std, there is no problem with compilation on osx 10.8 now.

@ahornung
Copy link
Member

ahornung commented Apr 8, 2013

I fixed the isnan issue in the latest commit, could you checkout (or download) the devel branch and confirm that it's compiling with OSX?

You can run "make test" afterwards to check if all unit tests succeed.

@smcgill3
Copy link
Author

smcgill3 commented Apr 8, 2013

I cloned the latest "devel" branch, ran cmake .. and then make. It seems to compile fine, but the make command results in:

make[2]: *** No rule to make target ../lib/liboctomap.so', needed by../lib/liboctovis.dylib'. Stop.
make[1]: *** [octovis/CMakeFiles/octovis-shared.dir/all] Error 2
make: *** [all] Error 2

for octovis. If I do "make octomap" however, everything works. I followed this up with "make test"

Running tests...
Test project /Users/stephen/src/octomap/octomap
      Start  1: MathVector
 1/14 Test  #1: MathVector .......................   Passed    0.00 sec
      Start  2: MathPose
 2/14 Test  #2: MathPose .........................   Passed    0.00 sec
      Start  3: InsertRay
 3/14 Test  #3: InsertRay ........................   Passed    1.09 sec
      Start  4: CastRay
 4/14 Test  #4: CastRay ..........................   Passed    0.45 sec
      Start  5: InsertScan
 5/14 Test  #5: InsertScan .......................   Passed    0.49 sec
      Start  6: ReadGraph
 6/14 Test  #6: ReadGraph ........................   Passed    0.02 sec
      Start  7: StampedTree
 7/14 Test  #7: StampedTree ......................***Failed    1.23 sec
      Start  8: OcTreeKey
 8/14 Test  #8: OcTreeKey ........................   Passed    0.01 sec
      Start  9: OcTreeIterator
 9/14 Test  #9: OcTreeIterator ...................   Passed    0.02 sec
      Start 10: test_pruning
10/14 Test #10: test_pruning .....................   Passed    0.03 sec
      Start 11: test_iterators
11/14 Test #11: test_iterators ...................   Passed    0.67 sec
      Start 12: test_io
12/14 Test #12: test_io ..........................   Passed    0.49 sec
      Start 13: test_mapcollection
13/14 Test #13: test_mapcollection ...............   Passed    0.22 sec
      Start 14: test_color_tree
14/14 Test #14: test_color_tree ..................***Exception: Other  0.13 sec

86% tests passed, 2 tests failed out of 14

Total Test time (real) =   4.88 sec

The following tests FAILED:
      7 - StampedTree (Failed)
     14 - test_color_tree (OTHER_FAULT)

Thanks!

@yida
Copy link

yida commented Apr 8, 2013

in octomap-config.cmake.in and octovis-config.cmake.in, library suffix has been hard coded as so while shared libs on osx ends with dylib. Quick work around can be

if (APPLE)
set(....dylin)
else()
set(...so)
endif()

@ahornung
Copy link
Member

ahornung commented Apr 8, 2013

The second problem are the tests. Two of them fail, can you run them separately from a terminal?

./test_color_tree
/unit_tests StampedTree

from octomap/bin.

@ahornung
Copy link
Member

ahornung commented Apr 8, 2013

Concerning your first problem: It looks like octovis can not be built against the octomap library ("make octovis", called by "make").

As yida wrote, OSX might need a workaround in the file octomap/octomap-config.cmake.in
You can find similar workarounds in octovis/CMakeLists_src.txt

@smcgill3
Copy link
Author

smcgill3 commented Apr 8, 2013

./test_color_tree
test_color_tree(641) malloc: *** error for object 0x7fecb9415508: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

I ran valgrind: stderr: http://pastebin.com/3rwqP9iB
stdout seems to indicate it worked, when under valgrind: http://pastebin.com/AQ3KYe4x

test_pruning yeilds an error:
test failed (EXPECT_TRUE) in /Users/stephen/src/octomap/octomap/src/testing/test_pruning.cpp, line 84

The stamped tree unit test works once in a while, but its error is:
After 1st update (cube): Tree time 1365441319; node(0.1, 0.1, 0.1) time 1365441319
After 2nd update (single miss): Tree time 1365441319; node(0.1, 0.1, 0.1) time 1365441319
After 3rd update (single hit at (0.1, 0.1, 0.3): Tree time 1365441320; node(0.1, 0.1, 0.1) time 3221227518; node(0.1, 0.1, 0.3) time 1365441320
test failed (EXPECT_TRUE) in /Users/stephen/src/octomap/octomap/src/testing/unit_tests.cpp, line 300

Let me know if this is helpful, or if you need more tests run. Thanks!

@smcgill3
Copy link
Author

smcgill3 commented Apr 8, 2013

I applied the simple apple patch. Running "git diff" yields: http://pastebin.com/QnbwPsMz

Running make octovis seems to get further, but ends with this error:
ld: library not found for -lQGLViewer
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [../lib/liboctovis.dylib] Error 1
make[2]: *** [octovis/CMakeFiles/octovis-shared.dir/all] Error 2
make[1]: *** [octovis/CMakeFiles/octovis.dir/rule] Error 2
make: *** [octovis] Error 2

I ran "grep -nR lQGLViewer ." because this seems to be a framework issue.

I replaced this line:

./octovis/CMakeFiles/octovis-shared.dir/link.txt:1:/usr/bin/c++ -O3 -DNDEBUG -dynamiclib -Wl,-headerpad_max_install_names -framework OpenGL -o ../../lib/liboctovis.dylib -install_name /Users/stephen/src/octomap/lib/liboctovis.dylib CMakeFiles/octovis-shared.dir/src/SceneObject.cpp.o CMakeFiles/octovis-shared.dir/src/PointcloudDrawer.cpp.o CMakeFiles/octovis-shared.dir/src/OcTreeDrawer.cpp.o CMakeFiles/octovis-shared.dir/src/SelectionBox.cpp.o CMakeFiles/octovis-shared.dir/src/TrajectoryDrawer.cpp.o CMakeFiles/octovis-shared.dir/src/ColorOcTreeDrawer.cpp.o -L/Library/Frameworks -framework OpenGL -framework AGL ../../lib/liboctomap.dylib ../../lib/liboctomath.dylib -lQGLViewer

with

/usr/bin/c++ -O3 -DNDEBUG -dynamiclib -Wl,-headerpad_max_install_names -framework OpenGL -o ../../lib/liboctovis.dylib -install_name /Users/stephen/src/octomap/lib/liboctovis.dylib CMakeFiles/octovis-shared.dir/src/SceneObject.cpp.o CMakeFiles/octovis-shared.dir/src/PointcloudDrawer.cpp.o CMakeFiles/octovis-shared.dir/src/OcTreeDrawer.cpp.o CMakeFiles/octovis-shared.dir/src/SelectionBox.cpp.o CMakeFiles/octovis-shared.dir/src/TrajectoryDrawer.cpp.o CMakeFiles/octovis-shared.dir/src/ColorOcTreeDrawer.cpp.o -L/Library/Frameworks -framework OpenGL -framework AGL ../../lib/liboctomap.dylib ../../lib/liboctomath.dylib -framework QGLViewer

I do a similar technique for another occurrence. The two commands, then, that I run in the "octomap/build/octovis" directory are: http://pastebin.com/8RtP9PfE

I can run make and then make install with this. A screenshot of octovis running with a tree made on the Mac is attached. CMake is not my forte, but I will look to see if there is a simple fix for this framework issue. For reference, libqglviewer was installed with homebrew, with the extra linking instruction it stipulates.

Screen Shot 2013-04-08 at 4 19 07 PM

@smcgill3
Copy link
Author

smcgill3 commented Apr 9, 2013

I may have a fix for the CMake issue, and the output of git diff is located here: http://pastebin.com/yA6qxLDz
make yields this on stderr:
/Users/stephen/src/octomap/octovis/src/CameraFollowMode.cpp:43:12: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare]
if(frame >= 0 && frame <= m_scan_graph->size()) {
~~~~~ ^ ~
1 warning generated.

if you think this is ever a concern.

With the linked patch, I build the whole thing with no errors, but do note that I am using Homebrew and NOT macports. Let me know if you need any more information. Thanks!

@ahornung
Copy link
Member

ahornung commented Apr 9, 2013

@smcgill3 Thanks! Could you fork octomap here on GitHub, push that fix to your fork and then create a pull request? That makes it much easier to integrate patches back.

I have no idea about the differences between Homebrew and Macports, so it would be good if someone using macports could test it. They can then directly do that from your fork.

@ahornung
Copy link
Member

I'm closing this issue, the remaining ones now have their own tickets for clarity: #24 for octovis CMake and #25 for the unit tests.

@tmdiv
Copy link
Contributor

tmdiv commented Sep 4, 2013

This fix makes problems in VC++. isnan() does not exist in VC++ and it is not std. This should help.

#define isnan(x) _isnan(x)
using namespace std;

@ahornung
Copy link
Member

ahornung commented Sep 4, 2013

@tmdiv Could you fork the current devel branch, push the fix to your fork if it compiles for you and send me a pull request? That will be much easier for me and I can directly test it.

@tmdiv
Copy link
Contributor

tmdiv commented Sep 4, 2013

I'm trying. I have problems with Pull request. Please give me some time.

@ahornung
Copy link
Member

ahornung commented Sep 4, 2013

Sure, no problem!

ahornung pushed a commit that referenced this issue Sep 5, 2013
Fix missing isnan in Visual C++ (relates to #23)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants