vigra @1.10.0_6 build fails with -Os

[macports@…]

Vigra @1.10.0_6 build fails at

:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vigra/vigra/work/vigra-1-10-0 && /opt/local/bin/cmake -E cmake_depends "Unix Makefiles" /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vigra/vigra/work/vigra-1-10-0 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vigra/vigra/work/vigra-1-10-0/vigranumpy/src/core /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vigra/vigra/work/vigra-1-10-0 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vigra/vigra/work/vigra-1-10-0/vigranumpy/src/core /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vigra/vigra/work/vigra-1-10-0/vigranumpy/src/core/CMakeFiles/vigranumpy_analysis.dir/DependInfo.cmake --color=
:info:build Undefined symbols for architecture x86_64:
:info:build   "std::__1::basic_ios<char, std::__1::char_traits<char> >::widen(char) const", referenced from:
:info:build       std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) in hdf5impex.cxx.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[2]: *** [src/impex/libvigraimpex.5.1.10.0.dylib] Error 1

[ryandesign (Ryan Carsten Schmidt)]

Likely due to yesterday's upgrade of hdf5 to 1.8.15; see #47743.

[mamoll (Mark Moll)]

I can reproduce the problem, but at the same time I can see that the symbol *is* defined in libc++:

> nm /usr/lib/libc++.dylib |c++filt|grep ::widen\(char\)
000000000000a7e4 unsigned short std::__1::basic_ios<char, std::__1::char_traits<char> >::widen(char) const
000000000000af16 unsigned short std::__1::basic_ios<wchar_t, std::__1::char_traits<wchar_t> >::widen(char) const

[mamoll (Mark Moll)]

Cc Me!

[BSeppke (Benjamin Seppke)]

First of all, I can reproduce the defect, too. But I am not (really) sure, if the origin of this error was the update of the hdf-Port. Since the last working status on my machine many ports have changed (like e.g. boost) and Apple came around with some new versions of the XCode-Framework (probably also new compilers?!).

I think, that this error has something to do with the new CMake-Portfile handling... Unfortunately I don't have any experience at how MacPorts adds/edits the CMake parameters in order to build the ports which are based on CMake, like vigra. So I tried to compile the "erroneous" vigra port on my own using just the arguments, which are stated inside the Portfile.

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vigra/vigra/work/vigra-1-10-0/
make clean
rm CMakeCache.txt

cmake -DCMAKE_INSTALL_PREFIX=/opt/local/ -DWITH_OPENEXR=ON -DCMAKE_CXX_FLAGS=-ftemplate-depth-1024 .

make 
make install

And now it is getting weird: This compiles! Without any errors! Can someone else reproduce this behavior and/or give me some (good) explanation why this compiles?

Update: I can even run

sudo port install vigra

after these changes, and the vigra port will be successfully installed by means of the MacPorts system.

Best wishes

Benjamin

[BSeppke (Benjamin Seppke)]

... after one day of intense testing and monitoring, I eventually found some reason for the error!

The error of this subject is more or less a clang error. The symbol is just not defined in the libc++ of clang++. Thus, we get the compiler/linker error during the compilation of the module. The (forced) setting to -stdlib=libstc++ temporary solves *this* issue, but hinders other things like the boost::python bindings to compile.

The real issue is described in comment:8

[mamoll (Mark Moll)]

Replying to benjamin.seppke@…:

The error of this subject is more or less a clang error. The symbol is just not defined in the libc++ of clang++.

But I think I showed in comment:3 that the symbol the compiler is complaining about is defined in libc++. What gives? I am confused.

[BSeppke (Benjamin Seppke)]

Hello,

you are right - and I was still confused regarding my last post. I edited it to avois any confusion here.

The error arises for the error (?!) inside the cmake defaults w.r.t. the clang++ build chain. In the default setting, this results in a CMakeCache.txt build config for Release like:

 CMAKE_CXX_FLAGS_RELEASE          -pipe -Os -DNDEBUG     

In the -Os optimization level some symbols of the std c++ lib are somehow lost. But if you replace the -Os with e.g. -O3 optimization, it compiles just as expected.

I have appended a Portfile-patch to this ticket, which solves this issue for me. Feel free to try it out and - if successful - please patch the macports Portfile for me. Unfortunately, I don't have write priviledges there.

[mamoll (Mark Moll)]

Committed in r136792.

[ryandesign (Ryan Carsten Schmidt)]

Replying to benjamin.seppke@…:

In the -Os optimization level some symbols of the std c++ lib are somehow lost. But if you replace the -Os with e.g. -O3 optimization, it compiles just as expected.

I haven't heard of anything like that before, but if that's true, then that's bizarre. Have you reported that problem to anyone else—the llvm project, for example, or Apple? -Os is the optimization level Apple uses to compile the software you get as part of OS X, so it's the optimization level that should be best-tested by Apple, who are also developers of llvm and clang and libc++, which is why MacPorts switched its default optimization level to -Os to match. If there is a problem with llvm/clang/libc++ and -Os I would very much like to know it, as probably would Apple.

[BSeppke (Benjamin Seppke)]

It really is the compiler's optimization flag, which causes this error. I didn't report this behaviour upstream (either LLVM or CLang) since I didn't have any more time e.g. to find/generate a minimal error case. Moreover, I'm not even sure, if this error is solely caused by the VIGRA library because the error just occured with a new version of hdf5.

So, if anyone has the time and capabilities to get deeper into this problem, feel invited :). But also be prepared that the error may

• either be caused by VIGRA's hdf5 impex or
• by the new hdf5 lib or
• somewhere in between.

And that it may take you a lot of time to generate a minimal error raising file.

But it is surely linked to the compiler settings - and vanishes if you got to -O3. I also did some "google" research on this issue (libc++ and optimization level) but did not find anything comparable.