Support for users with older versions of Xcode that what's on the build slaves

[Joshua Root]

On 2016-3-19 19:28 , Mojca Miklavec wrote:
> Hi,
>
> Recently a user issued a ticket with a problem that was most likely
> triggered by using an older version of Xcode than the one used for
> creating the binary package for Perl:
>      https://trac.macports.org/ticket/50894
>
> Perl does a number of configure-time checks and then hardcodes both
> the compiler and the flags to be used when installing C[++] code from
> CPAN.
>
> (ROOT does something similar which I find a bit annoying at times.)
>
> (a) One solution would be to unconditionally remove that flag for
> everyone (I don't know yet what the flag does, but I would assume it
> was added for some valid reason, so it would probably be desirable to
> keep it for systems that support it).
> (b) One solution would be to conditionally force removal of that flag
> (with some weird code; I don't know what condition would be best
> used).
> (c) One solution would be to close the ticket as 'wontfix' and ask the
> user to either:
>      - upgrade Xcode
>      - manually remove the flag
>      - install Perl from source or simply set "buildfromsource always"
> to avoid similar problems in the future
>
> The reverse problem can actually also happen after upgrading Xcode (if
> a flag would be removed from compiler and the user compiled perl
> before the upgrade, installing cpan modules could then fail because
> the new compiler would no longer accept the flag that was OK for the
> older one).
>
> I would be in favour of (c), but other opinions are welcome.

"Update your Xcode" is certainly the easiest resolution, and we have 
always recommended that users do that.

We've had several discussions in the past about compiler settings for 
use at runtime being baked in at build time, and why that's a bad idea. 
See e.g. <https://trac.macports.org/ticket/36474> and the linked ML 
thread, and this thread from later in the same year: 
<https://lists.macosforge.org/pipermail/macports-dev/2012-October/020736.html>

So it's also an upstream bug. You could patch perl to remove use of 
-fstack-protector-strong or replace it with -fstack-protector; that 
won't prevent anything from running since it's a hardening measure. 
Whether it "breaks" anything is a harder question. (Used on a bug-free 
program, it would do nothing but make it slightly slower.) Whether perl 
should even be choosing its own CFLAGS like this is left as an exercise 
for the reader. ;)

- Josh