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

Support
1

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 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[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?

2

@ihnorton suggested that it could be the wrong libiconv (probably from MacPorts) being picked up – that sounds reasonable. I’m investigating.

1 Like
3

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… :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?

4

More info: I started the SuperBuild with

cmake \
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.12 \
-DQT_QMAKE_EXECUTABLE=/opt/local/libexec/qt4/bin/qmake \
-DSlicer_USE_PYTHONQT_WITH_TCL=false \
$SRC_DIR

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.

5

@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

#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:

set(CMAKE_CXX_TARGET_INCLUDE_PATH
  "/opt/local/include"
  "config/include"
  "/Users/hmeine/Developer/MIC_OSS/Slicer/Slicer-SuperBuild-Debug/DCMTK/ofstd/include"
  "/Users/hmeine/Developer/MIC_OSS/Slicer/Slicer-SuperBuild-Debug/DCMTK/oflog/include"
  "/Users/hmeine/Developer/MIC_OSS/Slicer/Slicer-SuperBuild-Debug/DCMTK/dcmdata/include"
  "/Users/hmeine/Developer/MIC_OSS/Slicer/Slicer-SuperBuild-Debug/DCMTK/dcmimgle/include"
...

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?

2 Likes
6

Dropping a breadcrumb here so I can find this again next time I need it. Here is the explanation why ICU is not used: