dev-util/cmake has hardcoded paths in Modules/Platform/UnixPaths.cmake that cause it to link to libraries outside my sparc-solaris prefix. Also, ccmake fails to link against ncurses. Reproducible: Always Steps to Reproduce: 1. emerge dev-util/cmake Actual Results: /home/pub/lib/gentoo-prefix/usr/lib/gcc/sparc-sun-solaris2.10/4.2.4/../../../../sparc-sun-solaris2.10/bin/ld: warning: libm.so.1, needed by /opt/csw/lib/libstdc++.so, may conflict with libm.so.2 /tmp/chithanh/portage/dev-util/cmake-2.4.8/work/cmake-2.4.8/Source/libCMakeLib.a(cmMakefile.o): In function `char* std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_construct<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >(__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<char> const&, std::forward_iterator_tag)': cmMakefile.cxx:(.text._ZNSs12_S_constructIN9__gnu_cxx17__normal_iteratorIPKcSsEEEEPcT_S6_RKSaIcESt20forward_iterator_tag+0x234): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_M_set_length_and_sharable(unsigned int)' collect2: ld returned 1 exit status make[2]: *** [bin/DumpDocumentation] Error 1 Expected Results: build successfully I will attach a build log shortly. I have a patch to correct UnixPaths.cmake and will attach it after cleaning it up.
Created attachment 164609 [details] build.log build.log for cmake-2.4.8
It turns out that there are more hardcoded paths in the Modules/Find*.cmake files. They seem to be mostly unused however, I will try to find out which ones are important.
Anything I can do to help? I noticed cmake needs thorough fixing...
Created attachment 165123 [details, diff] cmake-2.6.1-prefix-unixpaths.patch patch for UnixPaths.cmake Under certain circumstances, cmake may still fail to link against libncurses, I am still investigating this.
Created attachment 165127 [details, diff] cmake-2.6.1-prefix-findcurses.patch This ugly workaround will prevent libcurses from /lib from being linked in. However this is probably not the best way. Suggestions welcome :)
Thanks for your patch. I slightly changed it to fix it in such a way that cmake looks in the prefix paths first. It make it find the right curses.
