Hi Torsten,

Great that you have made an early release of CMTK 3.0. Unfortunately the non-macports builds will be broken for most users because they include static links to the macports libz and libbz2:

$ otool -L /opt/local/bin/reformatx
/opt/local/bin/reformatx:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 832.0.0)

There are system installed versions of these libraries in 

/usr/lib/

and these are the ones that should be preferred in this build. I'm not sure how cmake determines the order of CMAKE_LIBRARY_PATH (is it determined by $PATH?).

Best,

Greg

Greg - 

I am not sure using system libz and libbz2 would make much of a difference. I would think the binaries would still depend on macports gcc runtime library, no?

Torsten

Originally posted by Torsten Rohlfing:
Nope. These builds currently use the system /gcc runtime libraries in /usr/lib (see the output from otool in my first message). It's just libz and libbz that are from macports. And since these are the _non_ macports builds, they should not use macports for libraries that will be present in essentially every command line tool in CMTK (Qt is another interesting issue ...).

Best,

Greg.

Here's a suggestion:

https://github.com/jefferis/cmtk/compare...

It doesn't break anything on my machine, but I don't have anything that cmtk wants in /opt/local.

Best,

G.

Originally posted by Greg Jefferis:
Oh, shoot, I missed that bit. Yes, of course, you are right - these builds should not be using MacPorts libraries at all.

I'll look into what's going on there.

Thanks!
TR

Okay - this was a bug in the top-level CMakeLists.txt, which added /opt/local/lib to the library search path whenever that directory existed, regardless of whether we were using MacPorts gcc or not.

This is fixed in r5183 and will be effective with CMTK 3.0.1.

Torsten

Hi Torsten and Greg:

Even with the macports build, i am having problems getting some command line tools to work.  For example, when i try to use registration or reformatx, I get the following error:

registration --help
dyld: lazy symbol binding failed: Symbol not found: __ZNSt8__detail15_List_node_base7_M_hookEPS0_
Referenced from: /opt/local/bin/registration
Expected in: /usr/lib/libstdc++.6.dylib

dyld: Symbol not found: __ZNSt8__detail15_List_node_base7_M_hookEPS0_
Referenced from: /opt/local/bin/registration
Expected in: /usr/lib/libstdc++.6.dylib
Trace/BPT trap: 5

Using otool, I think the problem is a bit different than Greg originally described, i.e., 

otool -L /opt/local/bin/registration
/opt/local/bin/registration:
/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6)
/opt/local/lib/libfftw3_threads.3.dylib (compatibility version 7.0.0, current version 7.2.0)
/opt/local/lib/libfftw3.3.dylib (compatibility version 7.0.0, current version 7.2.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.18.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Any suggestions?

- Erik

Hi Erik,

Sorry - looks like both Torsten and I missed your post last week. If you don't get a response within 48h then something is up!

The macports builds rely on even more macports stuff being installed than the non-macports build. So they are even less likely to work!

Torsten has fixed the build in what will become CMTK 3.0.1. I am not sure what his timeline for releasing that is – I imagine pretty soon – but that will be the simplest solution. Otherwise you need to compile from source. See e.g.

http://flybrain.mrc-lmb.cam.ac.uk/dokuwi...

But you need to install Apple Developer Tools aka Xcode and cmake before starting.

Best,

Greg.

Dear Erik,

Many thanks for your report (direct to me, excerpted below) of success building from source on OS X 10.9

As you say changes in 10.9 may well require a new cmake config, but in theory the only thing that would be essential to change is CMAKE_OSX_SYSROOT. CMAKE_OSX_DEPLOYMENT_TARGET can be a lower version although I am not sure if the 10.9 SDK can target as far back as 10.6. Moreover if you do find that an existing config is no longer working on a newer OS, you should always be able to do something like:

notice that ccmake is the (text based) GUI that is helpful for configuring cmake projects from scratch.

This should correctly set CMAKE_OSX_SYSROOT on any OSX version.

Best wishes,

Greg.

PS unfortunately although inspecting CMakeCache.txt files can be useful, they are almost never portable from one machine to the next.

> I think I have the command line tools working (though I want to work a little more extensively with them before I say so). It took a
> bit of scrambling, and It was a bit more complicated that expected, so I am sending this (see CMake file below) to you as I hope it will
> help with future versions.
>
> OSX10.4,10.5, and 10,6 all pu there SDK's in the same place, yet there were some significant changes with 10.9 (and I assume 10.8).
> The MacOSX10.9SDK is now in
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk (see line 179 that to the CMake file
> i'm attaching.
>
> Aside from that, I just changed the 10.6 expectations from CMake to 10.9. The version seems to be working, but I'll have to test it
> more to be sure.