Opened 10 years ago

Closed 10 years ago

#8931 closed bug (fixed)

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

Reported by: scottmc Owned by: jprostko
Priority: normal Milestone: R1/beta1
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


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

Change History (12)

comment:1 by leavengood, 10 years ago

Maybe hrev44581.

in reply to:  1 comment:2 by anevilyak, 10 years ago

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.

comment:3 by korli, 10 years ago

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

comment:5 by scottmc, 10 years ago

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...

comment:6 by scottmc, 10 years ago

Milestone: R1/alpha4R1/beta1
Priority: highnormal
Version: R1/alpha3R1/Development

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

comment:7 by jprostko, 10 years ago

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 from

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


#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 as:

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

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.

comment:8 by korli, 10 years ago

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

in reply to:  8 comment:9 by jprostko, 10 years ago

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.

comment:10 by jprostko, 10 years ago

Owner: changed from nobody to jprostko
Status: newassigned

comment:11 by jprostko, 10 years ago

Status: assignedin-progress

comment:12 by jprostko, 10 years ago

Resolution: fixed
Status: in-progressclosed

This should now be fixed as of hrev44704.

Note: See TracTickets for help on using tickets.