Build problem (unknown _libiconv symbols) on macOS (using MacPorts)

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 DCMTK-build, with

[ 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
"_libiconv_close", referenced from:
OFCharacterEncoding::Implementation::~Implementation() in
"_libiconv_open", referenced from:
OFCharacterEncoding::Implementation::create(OFString const&, OFString const&, OFCondition&) in
"_libiconvctl", referenced from:
OFCharacterEncoding::Implementation::getConversionFlags() const in
OFCharacterEncoding::Implementation::setConversionFlags(unsigned int) in
"_locale_charset", referenced from:
OFCharacterEncoding::Implementation::getLocaleEncoding() in
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[5]: *** [lib/libofstd.3.6.2.dylib] Error 1
make[4]: *** [ofstd/libsrc/CMakeFiles/ofstd.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [DCMTK-prefix/src/DCMTK-stamp/DCMTK-build] Error 2
make[1]: *** [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.

1 Like

Ok, so from 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… :wink:

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

cmake \
-DQT_QMAKE_EXECUTABLE=/opt/local/libexec/qt4/bin/qmake \

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/, the line

#include "dcmtk/config/osconfig.h"

picks up the wrong osconfig.h from /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?

Got it! 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: