The summary says it all. The log of the linking command failure: cc -lpthread -Wl,-E -fstack-protector-strong -L/usr/local/lib -o miniperl perlmini.o opmini.o miniperlmain.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.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 globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o -lpthread -lm -lcrypt -lutil perlmini.o: In function `Perl_sys_init3': perlmini.c:(.text+0x70): undefined reference to `__stack_chk_fail_local' perlmini.o: In function `S_forbid_setid': perlmini.c:(.text+0x10d): undefined reference to `__stack_chk_fail_local' perlmini.o: In function `Perl_populate_isa': ... This is on FreeBSD/i386 stable/9 (running in a jail on the stable/10 amd64 host, if this matter).
Can you get us the full build log ?
Created attachment 164224 [details] Build log Requested build log.
It seems you have some kind of local configuration that adds -fstack-protector-strong, can you remove it and see how it goes ?
(In reply to Mathieu Arnold from comment #3) I don't, or at least this was not an intent for any configuration I did. I have the following in the jail's make.conf: # $Id: make.conf,v 1.6 2015/04/24 20:56:27 root Exp root $ INSTALL_NODEBUG=yes #INSTALL=install -CS NO_PROFILE=true DOC_LANG=en_US.ISO8859-1 DISTDIR=/usr/local/arch/freebsd/distfiles WRKDIRPREFIX=/usr/home/portworkdir WRKDIRPREFIX=/usr/home/portworkdir32 DEFAULT_VERSIONS= perl5=5.22 ruby=2.2 TEX_DEFAULT=texlive GHOSTSCRIPT_DEFAULT=agpl #OSVERSION+= 1100036 #UNAME_ENV+= OSVERSION=${OSVERSION} OSVERSION+= 903508 UNAME_ENV+= UNAME_s=FreeBSD UNAME_ENV+= UNAME_r=9.3-STABLE UNAME_ENV+= UNAME_v="${UNAME_s} ${UNAME_r}" .MAKEFLAGS: ${UNAME_ENV} MAKE_ENV+= ${UNAME_ENV} CONFIGURE_ENV+= ${UNAME_ENV} SCRIPTS_ENV+= ${UNAME_ENV}
(In reply to Konstantin Belousov from comment #4) > (In reply to Mathieu Arnold from comment #3) > I don't, or at least this was not an intent for any configuration I did. I > have the following in the jail's make.conf: > It's strange, for some reason, the default -fstack-protector is changed to -fstack-protector-strong on your build, I guess it's missing -lssp to get the symbols it needs. Thing is, I can't reproduce the problem, so I'm not sure how to fix exactly your problem.
(In reply to Mathieu Arnold from comment #5) It is really not strange after looking at the code. Configure does the following: case "$gccversion" in ?*) set stack-protector-strong -fstack-protector-strong eval $checkccflag case "$dflt" in *-fstack-protector-strong*) ;; # It got added. *) # Try the plain/older -fstack-protector. set stack-protector -fstack-protector eval $checkccflag ;; esac ;; esac -fstack-protector-strong was added to stable/9 by r286714, the check for the flag passes, and the flag is used for compilation. Whatever is needed for linking, does not satisfy the perl build expectation, and the things break. It seems that -fstack-protector-strong is broken on stable/9 and should be patched out, at least in the perl Configure.
(In reply to Konstantin Belousov from comment #6) The problem is not really new and may apply to stack-protector as well: https://gcc.gnu.org/ml/gcc/2012-01/msg00012.html -current carries something like a stub in libc/secure/stack_protector_compat.c Perhaps adding -lssp for 9.x is the way to go.
Created attachment 164268 [details] Forcibly patch-out the -strict propolice
Created attachment 164269 [details] Build log with the proposed patch
(In reply to Konstantin Belousov from comment #8) The patch attached fixed the issue for me. I have no idea if the -fstack-protection-strict works on stable/10 and head (with clang), but if it is, you might want to only apply the patch conditionally. But I would not bother, -fstack-protection is almost useless.
(In reply to Konstantin Belousov from comment #10) For the record: no, stack protector "strong" doesn't work with the old clang in FreeBSD 10-stable. I agree that regular stack protector is basically useless. Eventually we will want to move away from the stack protector altogether as newer clang is offering alternatives.
https://svnweb.freebsd.org/ports/head/security/libsodium/Makefile?r1=373214&r2=378492
(In reply to Andriy Voskoboinyk from comment #12) Hmm ... If the affected ports keep growing, would it just be preferable to revert the stack-protector-strong support on 9.x? It would not be a problem to do so although the problem may resurface with newer GCCs.
(In reply to Pedro F. Giffuni from comment #13)- > although the > problem may resurface with newer GCCs. This should not happen until libc.so is a linker script (https://svnweb.freebsd.org/base?view=revision&revision=251668)
(In reply to Andriy Voskoboinyk from comment #12) --no-undefined is a request to stab your eye not now, but later, even if done for the dso, as done in the revision you referenced. This is not a solution. Either propolice does not catch anything, or it catches (unlikely), but instead of the message, the obscure rtld complain is shown. In the worst case, if static linker decided to generate static unresolved place, process would segfault. For binaries, this cannot work at all.
This has been silent a long time, is this still a problem, is the problem in Perl itself ? if not, can it be closed ?
(In reply to Mathieu Arnold from comment #16) Thank you for the reminder! No one commented on the convenience of removing the support on 9.x so I had forgotten about this. I doubt the functionality is all that important in 9.x so I will revert the change.
A commit references this bug: Author: pfg Date: Mon Mar 7 15:21:00 UTC 2016 New revision: 296456 URL: https://svnweb.freebsd.org/changeset/base/296456 Log: Revert r286714: Add a new option "-fstack-protector-strong". The stack-protector-strong option was causing problems when building perl5. This was never within the official featureset of the older GCC 4.x toolchain so just drop it to avoid patching the perl port. PR: 205307 Changes: _U stable/9/contrib/gcc/ stable/9/contrib/gcc/c-cppbuiltin.c stable/9/contrib/gcc/cfgexpand.c stable/9/contrib/gcc/common.opt stable/9/contrib/gcc/doc/cpp.texi stable/9/contrib/gcc/doc/gcc.1 stable/9/contrib/gcc/doc/invoke.texi stable/9/contrib/gcc/gcc.c
This should have been fixed now.