On Thu, Feb 06, 2003 at 08:42:19PM -0600, Chris Cheney wrote: Hello,
> I saw this when attempting to build arts on hppa: > > /usr/bin/ld: .libs/libmcop_la.all_cc.o(.text+0x3dfb4): cannot reach > 0000003e__ZNKSs7compareERKSs@@GLIBCPP_3.2+0, recompile with > -ffunction-sections > /usr/bin/ld: .libs/libmcop_la.all_cc.o(.text+0x3dfb4): cannot handle > R_PARISC_PCREL17F for std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::compare(std::basic_string<char, > std::char_traits<char>, std::allocator<char> > const&) const@@GLIBCPP_3.2 > /usr/bin/ld: final link failed: Bad value > collect2: ld returned 1 exit status > > http://buildd.debian.org/build.php?&pkg=arts&ver=1.1.0-2&arch=hppa&file=log > I am the person who reported the bug #179985 concerning this FTBFS. As written in the bug report, arts did build using -ffunction-sections. I don't understand exactly what it does, but it was suggested by ldd. If you want, the package is available on http://www.aurel32.net/kde_hppa/arts/ Is it the solution on hppa or only a workaround ? By the way, after that, I tried to build kdelibs from source. It fails the same manner. When using -ffunction-sections, it also failed, but a lot further. You can fetch the build logs on http://www.aurel32.net/kde_hppa/kdelibs It seems that in appears when linking very big .o files. Am I right ? In this case a workaround would be to compile kdelibs with --disable-final, as in this case the .cpp files are compiled indepently. Cheers, Aurelien
