I tried to compile CMake, branch next, revision 60b6b190cb569a18b6cf415d85ff59fa120a1035. The exact version isn't really important, the same behaviour can be produced with every CMake version from the next branch since at least 3 month. Before that I was running on gcc 4.4.x so I didn't see the issue. Using the released version 2.8.5 can also be used to provoke the error. I have a working version of CMake 2.8.4 installed, which was built with gcc 4.4.x (no idea with which exact version). Binutils used to build that CMake was very likely 2.20.1. If I just use "cmake /path/to/cmake/source/ && make" I get this result: Linking CXX executable ../bin/ccmake /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: libCMakeLib.a(cmGlobalGenerator.cxx.o)(.text._ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE16_M_insert_uniqueERKS4_[std::_Rb_tree<cmsys::String, std::pair<cmsys::String const, int>, std::_Select1st<std::pair<cmsys::String const, int> >, std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const, int> > >::_M_insert_unique(std::pair<cmsys::String const, int> const&)]+0xbc): cannot reach 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0, recompile with -ffunction-sections /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: libCMakeLib.a(cmGlobalGenerator.cxx.o)(.text._ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE16_M_insert_uniqueERKS4_[std::_Rb_tree<cmsys::String, std::pair<cmsys::String const, int>, std::_Select1st<std::pair<cmsys::String const, int> >, std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const, int> > >::_M_insert_unique(std::pair<cmsys::String const, int> const&)]+0xbc): cannot handle R_PARISC_PCREL17F for std::_Rb_tree<cmsys::String, std::pair<cmsys::String const, int>, std::_Select1st<std::pair<cmsys::String const, int> >, std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const, int> > >::_S_right(std::_Rb_tree_node_base*) /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status If I add -ffunction-section then ccmake (and cmake and cpack) build fine, but ctest fails: Linking CXX executable ../bin/ctest /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: libCMakeLib.a(cmMakefile.cxx.o)(.text._ZN10cmMakefile14AddSourceGroupEPKcS1_+0x40): cannot reach 00008647__ZNSaIcEC1Ev@@GLIBCXX_3.4+0, recompile with -ffunction-sections /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: libCMakeLib.a(cmMakefile.cxx.o)(.text._ZN10cmMakefile14AddSourceGroupEPKcS1_+0x40): cannot handle R_PARISC_PCREL17F for std::allocator<char>::allocator()@@GLIBCXX_3.4 /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status This is the same static library that causes problems, but this time on a different executable. So I think John is right and there is really a bug somewhere. Just for reference, this are the sizes of the binaries that I currently have on my system: -rwxr-xr-x 1 root root 3080228 Apr 26 12:51 /usr/bin/ccmake -rwxr-xr-x 1 root root 3050408 Apr 26 12:51 /usr/bin/cmake -rwxr-xr-x 1 root root 4092940 Apr 26 12:51 /usr/bin/ctest And this is what happens with -ffunction-sections for those that compile: -rwxr-xr-x 1 buildbot buildbot 9738726 Aug 26 09:15 ccmake -rwxr-xr-x 1 buildbot buildbot 9608066 Aug 26 09:16 cmake -rwxr-xr-x 1 buildbot buildbot 10302152 Aug 26 09:16 cpack I have no idea how big the current results would get as every of the 4 possible candidates fails to link. libCMakeLib.a is 21149998 bytes. If I use gcc 4.4.6 everything compiles fine but the result is broken. The compiled binary goes into an endless loop if I call the compiled binary with a source directory. This does not happen with arguments like "--help" or "--version". So: -compiling/linking with g++ 4.5 fails -compiling/linking with g++ 4.4 works, but the result is unusable I have not modified any settings when compiling CMake. See also https://bugs.gentoo.org/374465 for other problems compiling CMake on PA-RISC, no idea if this is related.
I am unable to duplicate this problem. I successfully built debian cmake_2.8.5-1 with both gcc-4.4 and 4.5. There were no testsuite errors in either case. My tools are: gcc version 4.4.6 (Debian 4.4.6-6) gcc version 4.5.3 (Debian 4.5.3-5) binutils 2.21.53.20110805 It is possible your tools are miscompiled. For example, some fixes to reorg were backported in May. These caused GCC to be miscompiled and produce incorrect code when optimizing at -O1 and above. Given that I can't duplicate the problem, further information is needed. You need to look at the object cmGlobalGenerator.cxx.o with objdump/readelf and see if the call site for the branch to __ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base is >= 240000 bytes from the start of the section containing the call. I think it more likely that this is a binutils problem.
> It is possible your tools are miscompiled. For example, some > fixes to reorg were backported in May. These caused GCC to be > miscompiled and produce incorrect code when optimizing at -O1 and above. > > Given that I can't duplicate the problem, further information is needed. Seems that trying to debug this issue now also destroyed the version I have on my system (or just the libstdc++, I don't know). What I did today is: rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed once again rebuild gcc 4.5.3 rebuild binutils 2.21.1 again created new build directory cd this build directory /path/to/cmake-next/configure make This fails with: /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: cmPropertyDefinitionMap.o(.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_[__gnu_cxx::new_allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, cmDocumentationSection*> >::construct(std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, cmDocumentationSection*>*, std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, cmDocumentationSection*> const&)]+0x54): cannot reach 000025c2__ZNSt4pairIKSsP22cmDocumentationSectionEC1ERKS3_+0, recompile with -ffunction-sections /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: cmPropertyDefinitionMap.o(.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_[__gnu_cxx::new_allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, cmDocumentationSection*> >::construct(std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, cmDocumentationSection*>*, std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, cmDocumentationSection*> const&)]+0x54): cannot handle R_PARISC_PCREL17F for std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, cmDocumentationSection*>::pair(std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, cmDocumentationSection*> const&) /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: final link failed: Bad value objdump shows this: objdump -x ./Bootstrap.cmk/cmPropertyDefinitionMap.o | grep _ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5 332 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 000000a0 00000000 00000000 00006008 2**2 00000000 l d .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 00000000 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 00000000 w F .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 000000a0 _ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 000009e0 R_PARISC_SEGREL32 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 000009e4 R_PARISC_SEGREL32 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_+0x0000009c 00000054 R_PARISC_PCREL17F _ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ RELOCATION RECORDS FOR [.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_]: 000013b0 R_PARISC_PCREL32 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_+0x00000008
> rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed > rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed once > again > rebuild gcc 4.5.3 > rebuild binutils 2.21.1 again > created new build directory > cd this build directory > /path/to/cmake-next/configure > make > > This fails with: Would you send me the exact source or a link to it offline? Is incremental linking being used? The branch is close to the start of the section and it's not obvious why it shouldn't be able to reach the stub. Could you try the failing link command with --stub-group-size=-1? Dave -- John David Anglin dave.anglin@bell.net
I see a similar error with cmake-next.
This is a binutils problem. Stubs and section merging don't play well together. I'll see if I can fix the default linker script. The error doesn't occur if the linker option '--unique=.text.*' is used.