perl fails to build with gcc4 - multiple definition of `__stack_chk_fail_local'

[scottmc]

Perl was building just a few weeks ago, so something has changed recently to cause this failure.

          CCCMD =  gcc -DPERL_CORE -c -fno-strict-aliasing -pipe -fstack-protector  -std=c89 -O -Wall -ansi -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat 
LIBRARY_PATH=/boot/common/develop/haikuports/dev-lang/perl/work/perl-5.10.1:%A/lib:/boot/home/config/lib:/boot/common/lib:/boot/system/lib gcc -fstack-protector -o miniperl \
      gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o  \
    miniperlmain.o opmini.o perlmini.o -lnetwork 
/boot/develop/abi/x86/gcc4/tools/gcc-4.6.2-haiku-120121/lib/gcc/i586-pc-haiku/4.6.2/../../../libssp.a(ssp.o): In function `__stack_chk_fail_local':
(.text+0x150): multiple definition of `__stack_chk_fail_local'
/boot/develop/abi/x86/gcc4/tools/gcc-4.6.2-haiku-120121/lib/gcc/i586-pc-haiku/4.6.2/../../../libssp_nonshared.a(libssp_nonshared_la-ssp-local.o):(.text+0x0): first defined here
collect2: ld returned 1 exit status
make: *** [miniperl] Error 1

[leavengood]

Maybe hrev44581.

[anevilyak]

Replying to leavengood:

Maybe hrev44581.

That one would have nothing to do with linking a 3rd party app. Only changes to gcc would trigger the above behavior. Either that or part of perl was built in shared mode and part wasn't.

[korli]

Seems related to the use of "-fstack-protector". Why it complains now and not before is beyond me.

[korli]

Andreas had a patch for this problem on 5.12 see ​http://lists.ports.haiku-files.org/pipermail/haikuports-devs-ports.haiku-files.org/2010-April/000917.html

[scottmc]

I've added Andreas' patch into the .bep for perl-5.10.1, it gets a bit further buth then it has another issue with fstack-protector. Perl takes a really long time to build on my setup, so perhaps someone with a faster setup and take a hack at this one? Otherwise we can just probably fall back to the r1a3 gcc4 package for now? It might just build fine in interactive build mode, I haven't tried that yet. I see the an x86_64 package was build for it recently...

[scottmc]

This only affects building the gcc4 perl package, so it should hold up the r1alpha4 release.

[jprostko]

Diger on IRC let me know of a fix to this issue (which also affects building CUPS).

The suggested fix basically comes down to changing ​http://cgit.haiku-os.org/buildtools/tree/gcc/gcc/gcc.c#n606 from

#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}"

to

#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all:-lssp}"

(In other words, getting rid of -lssp_nonshared from the link line).

I then took this suggestion, and locally have instead applied it to ​http://cgit.haiku-os.org/buildtools/tree/gcc/gcc/config/haiku.h as:

#ifndef TARGET_LIBC_PROVIDES_SSP
#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all:-lssp}"
#endif

By doing it this way, the change is cleaner, as it's not touching any core GCC files. It seems to work, although I suppose there's a chance for side effects. I am yet to build Perl and see what happens, but hope to later tonight.

This all said, I'm still not sure why the multiple definition happens in the first place. Perhaps something is getting pulled in from our libroot sources unintentionally? I admit I only did a cursory investigation up to this point, and probably should do more digging.

So yes, I can apply my above-mentioned fix (and produce another GCC package), although I don't know currently if that's just kind of a bandage for an underlying issue, and should be handled in a different manner.

If it's an accepted way to handle this issue, I can apply it pretty much whenever, as long as initial testing indicates things are well. Whether we want it done for R1A4 or not though should probably be discussed.

[korli]

Hi jprostko, the patch looks fine to me. Side effects are at least confined to the option fstack-protector.

[jprostko]

Replying to korli:

Hi jprostko, the patch looks fine to me. Side effects are at least confined to the option fstack-protector.

That is definitely true. I rebuilt Perl 5.10.1 with my locally-updated GCC, and it builds fine now.

I'll take on the ticket and close it out later today.

[jprostko]

This should now be fixed as of hrev44704.