Re: arts FTBFS on hppa: ld on hppa is buggy

[Aurelien Jarno <aurelien@aurel32.net>]

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