Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#47754 closed defect (fixed)

vigra @1.10.0_6 build fails with -Os

Reported by: macports@… Owned by: BSeppke (Benjamin Seppke)
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: Cc: mamoll (Mark Moll), ryandesign (Ryan Carsten Schmidt)
Port: vigra

Description

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

Attachments (2)

main.log (98.8 KB) - added by macports@… 9 years ago.
Portfile-patch.diff (494 bytes) - added by BSeppke (Benjamin Seppke) 9 years ago.

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by macports@…

Attachment: main.log added

comment:1 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to benjamin.seppke@…

comment:2 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

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

comment:3 Changed 9 years ago by 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

comment:4 Changed 9 years ago by mamoll (Mark Moll)

Cc: mmoll@… added

Cc Me!

comment:5 Changed 9 years ago by 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

Last edited 9 years ago by BSeppke (Benjamin Seppke) (previous) (diff)

comment:6 Changed 9 years ago by 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

Last edited 9 years ago by BSeppke (Benjamin Seppke) (previous) (diff)

comment:7 in reply to:  6 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by 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.

Changed 9 years ago by BSeppke (Benjamin Seppke)

Attachment: Portfile-patch.diff added

comment:9 Changed 9 years ago by mamoll (Mark Moll)

Resolution: fixed
Status: newclosed

Committed in r136792.

comment:10 in reply to:  8 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added
Summary: Vigra @1.10.0_6 build failsvigra @1.10.0_6 build fails with -Os

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.

comment:13 Changed 9 years ago by 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.

Note: See TracTickets for help on using tickets.