-rpath wont work when targeting Mac OS X 10.3 on 10.5

[sevan]

Fixes build on Leopard 10.5 where the use of -rpath fails with
ld: -rpath can only be used when targetting Mac OS X 10.5 or later.
Attempting to set MACOSX_DEPLOYMENT_TARGET is ignored.
We leave it set for 10.4 & prior as the linker would default to a deployment target of 10.1 on powerpc & 10.4 on intel builds and there's no issue with this on 10.4 currently.

[tonycoz]

The documentation for MACOSX_DEPLOYMENT_TARGET's effects are unfortunately poor :(

I couldn't find anything where perl adds -rpath on darwin based on MACOSX_DEPLOYMENT_TARGET*, so I assume the MACOSX_DEPLOYMENT_TARGET setting is making the toolchain use -rpath internally, causing the failure (let me know if I missed it).

* EU::MM uses it based on $Config{osvers}, but not MACOSX_DEPLOYMENT_TARGET

[sevan]

The documentation for MACOSX_DEPLOYMENT_TARGET's effects are unfortunately poor :(

I couldn't find anything where perl adds -rpath on darwin based on MACOSX_DEPLOYMENT_TARGET*, so I assume the MACOSX_DEPLOYMENT_TARGET setting is making the toolchain use -rpath internally, causing the failure (let me know if I missed it).

The compiler toolchain will default to using -rpath on 10.5 but having MACOSX_DEPLOYMENT_TARGET set to 10.3 prevents it from being used, so we raise MACOSX_DEPLOYMENT_TARGET in Perl since that's where the 10.3 setting originates from, rather than attempting to adapt the things so -rpath is not used (I haven't attempted it & unsure if it's possible).

[ryandesign]

The documentation for MACOSX_DEPLOYMENT_TARGET's effects are unfortunately poor :(

MACOSX_DEPLOYMENT_TARGET lets you specify the minimum OS version that should be able to run the compiled software. You thus can't use some features that were not available on that OS version. For example, you may be running Mac OS X 10.5 or later which supports rpath, but if you target 10.4 or earlier, then you cannot use rpath because the program loader on 10.4 would have no idea what to do with that.

More commonly, though not applicable in this case, you might want to target an older OS but still use features from a newer SDK if the user is running a newer OS. To facilitate this, any symbols available in your newer SDK but not available on the older deployment target are weak-linked into your binary. It's your responsibility to check at runtime whether such a symbol is non-null before calling it.

I couldn't find anything where perl adds -rpath on darwin based on MACOSX_DEPLOYMENT_TARGET*, so I assume the MACOSX_DEPLOYMENT_TARGET setting is making the toolchain use -rpath internally, causing the failure (let me know if I missed it).

No, -rpath is only used when requested explicitly. perl bundles ExtUtils::MakeMaker which adds -rpath. Originally it did so on all macOS versions which unsurprisingly caused build failures on 10.4 and earlier. It was changed to add the flag only when perl was built on Darwin 9 (a.k.a. Mac OS X 10.5) or later. But some perl versions bundle EU:MM versions that don't have this fix, and the fix is still erroneous; it needed to have been based on the current deployment target, not the OS version that had been current when perl was built.

Rather than check the deployment target, which can be tricky because there are so many ways to specify it, EU:MM could check if the linker emits an error when -rpath is used, and consequently not use it.

The compiler toolchain will default to using -rpath on 10.5 but having MACOSX_DEPLOYMENT_TARGET set to 10.3 prevents it from being used

No, -rpath is only used when it is requested. If you request it and the deployment target is less than 10.5, you get the error you reported in the description of this PR.

[sevan]

If you request it and the deployment target is less than 10.5, you get the error you reported in the description of this PR.

Confirmed. Just running env MACOSX_DEPLOYMENT_TARGET=10.4 ld -rpath foo (doesn't matter that foo doesn't exist) in a terminal, outside of perl, on a current version of macOS produces the error.