[Mrtrix-discussion] Linking error
Daan Christiaens
Daan.Christiaens at esat.kuleuven.be
Wed Oct 30 02:24:17 PDT 2013
Hi everyone,
I came across the same issue last week, when I was trying to compile MRtrix 2.11 on Mac OS X Mavericks. The simplest patch I found, was to add "-stdlib=libstdc++” and "-mmacosx-version-min=10.6” to cpp_flags, ld_flags and ld_lib_flags in the darwin.py configuration file. These flags basically force g++ to use the old standard library, such that unordered_map is again found under std::tr1. This also resolved other linking errors I got from libraries that were compiled against the old STL.
The Clang solution below could be a good way to go for future MRtrix releases, as would be support for the C++11 standard on a more general note. However, as a quick fix to the current release, I though the two flags above could be useful to some of you.
Best regards,
Daan
ir. Daan Christiaens
Ph.D. Researcher
<mailto:daan.christiaens at uzleuven.be>daan.christiaens at esat.kuleuven.be<mailto:daan.christiaens at esat.kuleuven.be>
tel +32 16 34 90 42
fax +32 16 34 90 01
Medical Image Computing – ESAT/PSI – Department of Electrical Engineering
Medical Imaging Research Center<http://www.medicalimagingcenter.be/> | Katholieke Universiteit Leuven<http://www.kuleuven.be/> | campus Gasthuisberg<http://www.uzleuven.be/> | Herestraat 49 bus 7003 | B - 3000 Leuven
From: Jon Clayden <jon.clayden at gmail.com<mailto:jon.clayden at gmail.com>>
Date: Tuesday 29 October 2013 16:38
To: Jeurissen Ben <ben.jeurissen at uantwerpen.be<mailto:ben.jeurissen at uantwerpen.be>>
Cc: mrtrix mailinglist <mrtrix-discussion at public.nitrc.org<mailto:mrtrix-discussion at public.nitrc.org>>
Subject: Re: [Mrtrix-discussion] Linking error
Hi Ben,
Thanks for the heads-up. I did look into this, but it didn't sound as simple as you say. I'll try it locally in the first instance.
All the best,
Jon
On 28 October 2013 23:06, Jeurissen Ben <ben.jeurissen at uantwerpen.be<mailto:ben.jeurissen at uantwerpen.be>> wrote:
Hi Jon,
Thanks for your patch! I came across the same issues and had to apply similar patches.
One thing that I'm not sure of in your patch is the removal of -DUSE_TR1 in the CPP flags.
While this fixes the compile error of tr1/unordered_map not being found, it instead defaults to the older hash_map.
Using clang, unordered_map seems to live in the root of the standard library and directly in the std namespace.
So you can keep using the unordered_map with clang by removing the "tr1" path from the include and removing tr1:: from the HASH_MAP_TYPE define in case __clang__ is defined.
Cheers,
Ben
________________________________________
From: mrtrix-discussion-bounces at public.nitrc.org<mailto:mrtrix-discussion-bounces at public.nitrc.org> [mrtrix-discussion-bounces at public.nitrc.org<mailto:mrtrix-discussion-bounces at public.nitrc.org>] on behalf of Jon Clayden [jon.clayden at gmail.com<mailto:jon.clayden at gmail.com>]
Sent: 28 October 2013 17:54
To: Donald Tournier
Cc: mrtrix mailinglist
Subject: Re: [Mrtrix-discussion] Linking error
It looks like that instinct was correct. Tweaking the code to get it to compile with Clang seems to have done the job. FWIW, the patch is below: Clang is picky about "ambiguous" calls to round(), which can be fixed easily by adding an explicit scope. This may be useful to others building on recent versions of OS X.
All the best,
Jon
--
diff --git a/cmd/mrtransform.cpp b/cmd/mrtransform.cpp
index d09d78b..2862667 100644
--- a/cmd/mrtransform.cpp
+++ b/cmd/mrtransform.cpp
@@ -147,9 +147,9 @@ EXECUTE {
opt = get_options (6); // upsample
if (opt.size()) {
float factor = opt[0][0].get_float();
- header.axes.dim[0] = round (header.axes.dim[0] * factor);
- header.axes.dim[1] = round (header.axes.dim[1] * factor);
- header.axes.dim[2] = round (header.axes.dim[2] * factor);
+ header.axes.dim[0] = MR::round (header.axes.dim[0] * factor);
+ header.axes.dim[1] = MR::round (header.axes.dim[1] * factor);
+ header.axes.dim[2] = MR::round (header.axes.dim[2] * factor);
header.axes.vox[0] /= factor;
header.axes.vox[1] /= factor;
header.axes.vox[2] /= factor;
diff --git a/cmd/streamtrack.cpp b/cmd/streamtrack.cpp
index 61e45f1..1b08ed7 100644
--- a/cmd/streamtrack.cpp
+++ b/cmd/streamtrack.cpp
@@ -259,7 +259,7 @@ class Threader {
max_num_attempts = to<guint> (properties["max_num_attempts"]);
unidirectional = to<int> (properties["unidirectional"]);
- min_size = round (to<float> (properties["min_dist"]) / to<float> (properties["step_size"]));
+ min_size = MR::round (to<float> (properties["min_dist"]) / to<float> (properties["step_size"]));
writer.create (output_file, properties);
}
diff --git a/sysconf/darwin.py b/sysconf/darwin.py
index a675462..9f62666 100644
--- a/sysconf/darwin.py
+++ b/sysconf/darwin.py
@@ -5,14 +5,14 @@ exe_suffix = ''
lib_prefix = 'lib'
lib_suffix = '.dylib'
-cpp = [ 'g++', '-c', '$flags$', '$gtk$', '$path$', '$src$', '-o', '$obj$' ]
-cpp_flags = [ '-Wall', '-mtune=native', '-fPIC', '-fno-strict-aliasing', '-DGL_GLEXT_PROTOTYPES', '-DUSE_TR1' ]
+cpp = [ 'clang++', '-c', '$flags$', '$gtk$', '$path$', '$src$', '-o', '$obj$' ]
+cpp_flags = [ '-Wall', '-mtune=native', '-fPIC', '-fno-strict-aliasing', '-DGL_GLEXT_PROTOTYPES' ]
-ld = [ 'g++', '$flags$', '$path$', '$obj$', '$mrtrix$', '$gsl$', '$gtk$', '$lz$', '-o', '$bin$' ]
+ld = [ 'clang++', '$flags$', '$path$', '$obj$', '$mrtrix$', '$gsl$', '$gtk$', '$lz$', '-o', '$bin$' ]
ld_flags = []
ld_flags_lib_prefix = '-l'
-ld_lib = [ 'g++', '-shared', '$flags$', '$obj$', '-o', '$lib$' ]
+ld_lib = [ 'clang++', '-shared', '$flags$', '$obj$', '-o', '$lib$' ]
ld_lib_flags = []
# look for MacPorts or FINK dependencies, and act accordingly if found:
On 28 Oct 2013, at 16:18, Jon Clayden <jon.clayden at gmail.com<mailto:jon.clayden at gmail.com>> wrote:
> Hi Donald,
>
> Thanks for the quick reply. Unfortunately I've already tried cleaning up first, and it doesn't help.
>
> Clang is now the default compiler on OS X, and I think Homebrew uses it by default too. So the only other thing I can think of is that Clang uses different name-mangling to GCC and therefore that the symbols don't match up. They're definitely there in some form:
>
> $ nm -arch x86_64 -g /usr/local/Cellar/glibmm/2.38.0/lib/libglibmm-2.4.dylib | grep build_filename
> 0000000000017261 T __ZN4Glib14build_filenameERKNS_11ArrayHandleINSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEENS_17Container_Helpers10TypeTraitsIS7_EEEE
> 00000000000172ce T __ZN4Glib14build_filenameERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEES8_
> 000000000001735d T __ZN4Glib14build_filenameERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEES8_S8_
> 00000000000173fd T __ZN4Glib14build_filenameERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEES8_S8_S8_
> 00000000000174b0 T __ZN4Glib14build_filenameERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEES8_S8_S8_S8_
> 0000000000017575 T __ZN4Glib14build_filenameERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEES8_S8_S8_S8_S8_
> 000000000001765c T __ZN4Glib14build_filenameERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEES8_S8_S8_S8_S8_S8_
> 000000000001775a T __ZN4Glib14build_filenameERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEES8_S8_S8_S8_S8_S8_S8_
> 000000000001786f T __ZN4Glib14build_filenameERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEES8_S8_S8_S8_S8_S8_S8_S8_
> U _g_build_filename
> U _g_build_filenamev
>
> Unfortunately MRtrix won't build out of the box with Clang, so I can't quickly try that. I'll keep plugging away at it.
>
> All the best,
> Jon
>
>
> On 28 Oct 2013, at 15:25, Donald Tournier <jdtournier at gmail.com<mailto:jdtournier at gmail.com>> wrote:
>
>> Hey Jon,
>>
>> Seems odd, but my best guess would be that these functions might have changed from being actual functions calls to now being header-only inline functions, which would therefore not be present in the library. If that's the case, it would only be a problem if you're trying to link already compiled code, which would happen if you're trying to build from your previous installation without issuing a './build clean' first to remove all already compiled object files.
>>
>> So in brief, try './build clean', then './build'...
>>
>> Cheers,
>> Donald.
>>
>>
>>
>> On 28 October 2013 15:11, Jon Clayden <jon.clayden at gmail.com<mailto:jon.clayden at gmail.com>> wrote:
>> Dear all,
>>
>> I know this is tedious--sorry--but I've been struggling to get MRtrix installed on a new computer (Mac OS X Mavericks + Homebrew) and can't find my way past this problem.
>>
>> The MRtrix build script fails at link time (see output below). But the library paths look fine, the appropriate libraries are listed in the link command generated by the script, and I see no evidence that the functions in question have moved or been removed in recent versions of glibmm (I'm using 2.38.0).
>>
>> Am I missing something obvious here?
>>
>> Thanks in advance,
>> Jon
>>
>> --
>> [LD] lib/libmrtrix-0_2_11.dylib
>>
>> ERROR: [LD] lib/libmrtrix-0_2_11.dylib
>>
>> g++-4.8 -shared lib/math/vector.o lib/math/matrix.o lib/image/format/analyse.o lib/file/dicom/quick_scan.o lib/image/format/list.o lib/file/dicom/image.o lib/file/config.o lib/point.o lib/image/name_parser.o lib/image/format/xds.o lib/data_type.o lib/args.o lib/file/dicom/patient.o lib/file/dicom/tree.o lib/image/fft.o lib/image/header.o lib/file/dicom/mapper.o lib/file/dicom/select_cmdline.o lib/math/linalg.o lib/file/dicom/study.o lib/file/dicom/element.o lib/file/mmap.o lib/image/format/nifti1.o lib/file/dicom/dict.o lib/image/format/mrtrix.o lib/image/format/base.o lib/image/axis.o lib/image/interp.o lib/image/mapper.o lib/file/dicom/series.o lib/mrtrix.o lib/image/format/mri.o lib/image/object.o lib/image/format/dicom.o lib/app.o lib/file/key_value.o -L/usr/local/Cellar/glibmm/2.38.0/lib -L/usr/local/Cellar/glib/2.38.1/lib -L/usr/local/Cellar/libsigc++/2.3.1/lib -L/usr/local/Cellar/glib/2.38.1/lib -L/usr/local/opt/gettext/lib -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lgt
hre
>> ad-2.0 -lglib-2.0 -lintl -lgsl -lgslcblas -lz -o lib/libmrtrix-0_2_11.dylib
>>
>> failed with output:
>>
>> Undefined symbols for architecture x86_64:
>> "Glib::build_filename(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
>> MR::File::Config::init() in config.o
>> MR::Image::NameParser::name(std::vector<int, std::allocator<int> > const&) in name_parser.o
>> MR::Image::NameParser::get_next_match(std::vector<int, std::allocator<int> >&, bool) in name_parser.o
>> MR::File::Dicom::Tree::read_dir(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in tree.o
>> MR::Image::Format::MRtrix::read(MR::Image::Mapper&, MR::Image::Header&) const in mrtrix.o
>> "Glib::str_has_suffix(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
>> MR::Image::Format::Analyse::check(MR::Image::Header&, int) const in analyse.o
>> MR::Image::Format::Analyse::read(MR::Image::Mapper&, MR::Image::Header&) const in analyse.o
>> MR::Image::Format::XDS::check(MR::Image::Header&, int) const in xds.o
>> MR::Image::Format::XDS::read(MR::Image::Mapper&, MR::Image::Header&) const in xds.o
>> MR::File::Dicom::Element::set(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in element.o
>> MR::Image::Format::NIfTI::check(MR::Image::Header&, int) const in nifti1.o
>> MR::Image::Format::NIfTI::create(MR::Image::Mapper&, MR::Image::Header const&) const in nifti1.o
>> ...
>> "Glib::path_get_dirname(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
>> MR::Image::NameParser::parse(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) in name_parser.o
>> MR::Image::Format::MRtrix::read(MR::Image::Mapper&, MR::Image::Header&) const in mrtrix.o
>> "Glib::path_get_basename(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
>> MR::Image::NameParser::parse(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) in name_parser.o
>> MR::Image::Format::MRtrix::create(MR::Image::Mapper&, MR::Image::Header const&) const in mrtrix.o
>> MR::Image::Object::open(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) in object.o
>> MR::Image::Object::create(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, MR::Image::Header&) in object.o
>> MR::App::App(int, char**, char const**, MR::Argument const*, MR::Option const*, unsigned int const*, char const*, char const*) in app.o
>> MR::App::App(int, char**, char const**, MR::Argument const*, MR::Option const*, unsigned int const*, char const*, char const*) in app.o
>> "Glib::Dir::Dir(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
>> MR::Image::NameParser::get_next_match(std::vector<int, std::allocator<int> >&, bool) in name_parser.o
>> MR::File::Dicom::Tree::read_dir(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in tree.o
>> "Glib::ustring::ustring(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
>> MR::Math::Vector::save(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const in vector.o
>> MR::Math::Vector::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in vector.o
>> MR::Math::Matrix::save(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const in matrix.o
>> MR::Math::Matrix::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in matrix.o
>> MR::Image::NameParser::get_next_match(std::vector<int, std::allocator<int> >&, bool) in name_parser.o
>> MR::Image::Format::XDS::read(MR::Image::Mapper&, MR::Image::Header&) const in xds.o
>> MR::Image::Format::XDS::create(MR::Image::Mapper&, MR::Image::Header const&) const in xds.o
>> ...
>> "Glib::file_test(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Glib::FileTest)", referenced from:
>> MR::File::Config::init() in config.o
>> MR::Image::NameParser::parse(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) in name_parser.o
>> MR::File::Dicom::Tree::read_dir(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in tree.o
>> MR::File::Dicom::Tree::read(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in tree.o
>> MR::Image::Format::MRtrix::create(MR::Image::Mapper&, MR::Image::Header const&) const in mrtrix.o
>> "Glib::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Glib::ustring const&)", referenced from:
>> MR::cmdline_info(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in app.o
>> MR::cmdline_error(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in app.o
>> MR::cmdline_debug(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in app.o
>> MR::operator<<(std::basic_ostream<char, std::char_traits<char> >&, MR::App const&) in app.o
>> ld: symbol(s) not found for architecture x86_64
>> collect2: error: ld returned 1 exit status
>>
>> STOP
>> _______________________________________________
>> Mrtrix-discussion mailing list
>> Mrtrix-discussion at www.nitrc.org<mailto:Mrtrix-discussion at www.nitrc.org>
>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>>
>>
>>
>> --
>> Dr J-Donald Tournier (PhD)
>>
>> Senior Lecturer, Biomedical Engineering
>> Division of Imaging Sciences & Biomedical Engineering
>> King's College London
>>
>> A: Department of Perinatal Imaging & Health, 1st Floor South Wing, St Thomas' Hospital, London. SE1 7EH
>> T: +44 (0)20 7188 7118 ext 53613<tel:%2B44%20%280%2920%207188%207118%20ext%2053613>
>> W: http://www.kcl.ac.uk/medicine/research/divisions/imaging/departments/biomedengineering
>
_______________________________________________
Mrtrix-discussion mailing list
Mrtrix-discussion at www.nitrc.org<mailto:Mrtrix-discussion at www.nitrc.org>
http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20131030/a447cec1/attachment-0001.html>
More information about the Mrtrix-discussion
mailing list