I am trying to compile Slicer on macOS 10.12.6 with XCode 9.1. Homebrew is not installed, I am using MacPorts.
My SuperBuild fails in
[ 2%] Linking CXX shared library …/…/lib/libofstd.dylib
Undefined symbols for architecture x86_64:
"_libiconv", referenced from:
OFCharacterEncoding::Implementation::convert(OFString&, char const*, unsigned long) in ofchrenc.cc.o
"_libiconv_close", referenced from:
OFCharacterEncoding::Implementation::~Implementation() in ofchrenc.cc.o
"_libiconv_open", referenced from:
OFCharacterEncoding::Implementation::create(OFString const&, OFString const&, OFCondition&) in ofchrenc.cc.o
"_libiconvctl", referenced from:
OFCharacterEncoding::Implementation::getConversionFlags() const in ofchrenc.cc.o
OFCharacterEncoding::Implementation::setConversionFlags(unsigned int) in ofchrenc.cc.o
"_locale_charset", referenced from:
OFCharacterEncoding::Implementation::getLocaleEncoding() in ofchrenc.cc.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [lib/libofstd.3.6.2.dylib] Error 1
make: *** [ofstd/libsrc/CMakeFiles/ofstd.dir/all] Error 2
make: *** [all] Error 2
make: *** [DCMTK-prefix/src/DCMTK-stamp/DCMTK-build] Error 2
make: *** [CMakeFiles/DCMTK.dir/all] Error 2
Does that look familiar to anyone?
@ihnorton suggested that it could be the wrong libiconv (probably from MacPorts) being picked up – that sounds reasonable. I’m investigating.
Ok, so from https://issues.slicer.org/view.php?id=2006 I thought that libiconv would not be needed and deactivated. In CMake, I can see that
DCMTK_WITH_ICONV is disabled.
Still, I tried to
port deactivate libiconv, confirming that I want to do that despite ~40 packages depend on it, but then CMake was one of these…
There’s also a libiconv in /usr (macOS-provided, I assume), which gets picked up first when I enable
DCMTK_WITH_ICONV. Building with
DCMTK_WITH_ICONV and either the /usr or the /opt/local (MacPorts) version did not work, either. (Leading to the exact same linker error.)
So, back to square one: Why am I getting these missing symbols when
DCMTK_WITH_ICONV is disabled, as it should be, in the first place?
More info: I started the SuperBuild with
and Qt is version 4.8.7_5 (although that shouldn’t make a difference for dcmtk, AFAICS). I also tried a fresh build with
CMAKE_OSX_DEPLOYMENT_TARGET=10.11, FWIW. CMake is 3.10.1.
On @che85’s machine with Sierra, but HomeBrew instead of MacPorts, we managed to compile the same code.
@ihnorton and I debugged this further and ultimately found the culprit:
In the out-of-source build of
DCMTK/ofstd/libsrc/ofchrenc.cc, the line
picks up the wrong
/opt/local/include (MacPorts) which has ICONV enabled.
Now one solution would be to disable / remove that dcmtk. However, I wonder where the include path comes from, which is defined like this:
As you can see, the dcmtk build & source directories immediately follow the culprit, so why is that one in front?
DCMTK_WITH_ICU was enabled! Now I can build. Still, I wonder why this flag leads to the include path being prepended instead of appended after the superbuild-paths. Maybe someone subscribed to dcmtk lists or involved in dcmtk and its CMake system would like to fix this?
Dropping a breadcrumb here so I can find this again next time I need it. Here is the explanation why ICU is not used: