perl5.28: configures with -L/opt/local/lib but strips that out during the build

[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 why 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+?

[kencu (Ken)]

Lots of reports of this error on the net with many different packages.

disabling the patch would fail still if some version of libgcc was not installed to supply the library.

I think we might need to instead turn off -fstack-protector on gcc-4.2 which doesn't seem to support it.

[ryandesign (Ryan Carsten Schmidt)]

This was the only place I found a reference to libssp_nonshared, in the apple-gcc42 source code in gcc/gcc.c:

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

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

$ 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

port provides /opt/local/lib/libssp_nonshared.a?

[ryandesign (Ryan Carsten Schmidt)]

Maybe apple-gcc42 detected the presence of /opt/local/lib/libssp_nonshared.a (or /opt/local/lib/libssp.a if you have it) and decided that it should link with those libraries when -fstack-protector or -fstack-protector-all is requested. So the fix may be to remove /opt/local/lib/libssp_nonshared.a (and /opt/local/lib/libssp.a if you have it) and then rebuild apple-gcc42.

[ryandesign (Ryan Carsten Schmidt)]

Is it possible that you used a newer gcc port to build apple-gcc42, like you've done with other ports? If so maybe that explains why it thought the toolchain supported stack-protector and baked that assumption into apple-gcc42. If so, rebuild apple-gcc42 with the default compiler.

[kencu (Ken)]

No, I built apple-gcc4.2 with apple-gcc4.2+bootstrap.

I think I figured this out. On Intel systems only, perl tests to see if the compiler accepts the -fstack-protector flag during configure:

	# on x86_64 (at least) we require an extra library (libssp) in the
	# link command line. This library is not named, so I infer that it is
	# an implementation detail that may change. Hence the safest approach
	# is to add the flag to the flags passed to the compiler at link time,
	# as that way the compiler can do the right implementation dependant
	# thing. (NWC)
	case "$osname" in
	amigaos) ;; # -fstack-protector builds but doesn't work
	*)	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
		;;
	esac

apple-gcc4.2 happily accepts that flag without error:

/opt/local/bin/gcc-apple-4.2 -c -fstack-protector hello.c

but if you actually try to link something, it fails.

$ /opt/local/bin/gcc-apple-4.2 -fstack-protector hello.c
ld: library not found for -lssp_nonshared
collect2: ld returned 1 exit status

if somehow there is a reference to -L/opt/local/lib thrown in there, which there often is, and if there happens to be a libssp_nonshared in /opt/local/lib courtesy of some other libgcc, then it will work, by accident.

So -- apple-gcc4.2 should reject the flag, but it doesn't.

We're like the amigaos case in perl's configure script.

What we should do is strip -fstack-protector-* out of the configure script, at least systems where MacPorts defaults to a gcc < 4.9, like this patch you found. <​https://patchwork.openembedded.org/patch/134607/>

[ryandesign (Ryan Carsten Schmidt)]

But again, what port provided /opt/local/lib/libssp_nonshared.a on your system? And in the code above, I see the mention of x86_64 in the comment but I don't see where the code is only checking for stack-protector on Intel.

[kencu (Ken)]

I'm not sure how I can explain any clearer.

[kencu (Ken)]

I'll put up a PR with this patch in it.

[kencu (Ken)]

so it turns out that indeed the /opt/local/lib/libssp_nonshared.a that was present was making the the gcc-4.2 compiler test for -fstack-protector pass when it should have failed, with the default linker flags for MacPorts set to look there.

This is my doing, have to own it. No other way it could have got there. The file was dated April 2, right when I was making changes to get llvm7 and libc++ on Tiger, so I must have copied that library there to make some build work, and then forgot about it.

Apologies for noise.

[kencu (Ken)]

So - after finally sorting out what is really going on here -- the perl ports run configure with an environment that includes this:

LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'

but then later on manually strip out -L/opt/local/lib with a patch during the build.

This causes this error, and will most likely cause errors in the future with other builds.

This is a bug in the perl port.