Bug 236740 – make dev-util/cmake build in a solaris prefix

• Product: Gentoo/Alt
• Status: RESOLVED FIXED

[Description Chí-Thanh Christopher Nguyễn 2008-09-04 19:35:48 UTC]

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.

[Comment 1 Chí-Thanh Christopher Nguyễn 2008-09-04 19:40:42 UTC]

Created attachment 164609 [details]
build.log

build.log for cmake-2.4.8

[Comment 2 Chí-Thanh Christopher Nguyễn 2008-09-09 23:12:29 UTC]

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.

[Comment 3 Fabian Groffen 2008-09-10 08:37:48 UTC]

Anything I can do to help?  I noticed cmake needs thorough fixing...

[Comment 4 Chí-Thanh Christopher Nguyễn 2008-09-10 14:14:20 UTC]

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.

[Comment 5 Chí-Thanh Christopher Nguyễn 2008-09-10 15:03:51 UTC]

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

[Comment 6 Fabian Groffen 2008-09-11 18:56:24 UTC]

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.