perl5.28: fails on Tiger Intel : ld: library not found for -lssp_nonshared

[kencu (Ken)]

the perl ports all have a ​patch to strip out linking against anything in ${prefix}/lib . This apparently was causing errors in the past (a number of tickets with various ports) due to MacPorts libraries being called in instead of system libraries, and that would have inconsistencies, be non-universal, etc.

However, when building with the standard apple-gcc42 compiler on Tiger i386, the build fails due to this:

:info:build unset LIBRARY_PATH && /opt/local/bin/gcc-apple-4.2  -Wl,-headerpad_max_install_names -arch i386 -fstack-protector -force_flat_namespace -o miniperl \
:info:build     opmini.o perlmini.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 dquote.o time64.o  miniperlmain.o  -lpthread -ldl -lm -lc 
:info:build ld: library not found for -lssp_nonshared

That library exists only in ${prefix}/lib and so when the path is stripped out, the build fails.

$ locate libssp_nonshared
/opt/local/lib/gcc48/libssp_nonshared.a
/opt/local/lib/gcc48/libssp_nonshared.la
/opt/local/lib/gcc6/libssp_nonshared.a
/opt/local/lib/gcc6/libssp_nonshared.la
/opt/local/lib/gcc7/libssp_nonshared.a
/opt/local/lib/gcc7/libssp_nonshared.la
/opt/local/lib/libssp_nonshared.a

I don't know what apple-gcc42 would be asking for that library at all. It doesn't seem to supply it:

$ port contents apple-gcc42 | grep libssp
--nothing---

and this same error does not happen on TigerPPC, only on Intel.

Of course, building with any macports-gcc-N compiler fails with a weird error too, due to that patch:

:info:build ld: library not found for /libgcc

because the path /opt/local/lib/libgcc is stripped down to /libgcc. So that is another independent issue with this patch, but building with a macports gcc compiler is not a fix.

The only fix that works is to disable the patch completely, and then per5.2X will build. On Intel.

I don't yet know about 10.5 Intel, or what happens to 10.6 to 10.8 if they are not set up to use libc++ , which I guess is where the errors were seen in the first place.

For now - unless we sort out why that library is being asked for in the first place and fix that, we might just restrict the patch to -- 10.6+?