Front page | perl.perl5.porters |
Postings from October 2015
Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Thread Previous
|
Thread Next
From:
Craig A. Berry
Date:
October 14, 2015 22:23
Subject:
Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Message ID:
CA+vYcVw_6r1amd7jxXdsBdoMa7VrYm3OUu+j1bZBXX0H1WP5eg@mail.gmail.com
On Wed, Oct 14, 2015 at 3:45 PM, Jarkko Hietaniemi
<perlbug-followup@perl.org> wrote:
> # New Ticket Created by Jarkko Hietaniemi
> # Please include the string: [perl #126360]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org/Ticket/Display.html?id=126360 >
>
>
> Based on a discussion I had with the macports developers
>
> https://trac.macports.org/ticket/49273
>
> I would recommend doing *something* about the current setup where we set the binary backward compatibility to 10.3 (OS X is now at 10.11, 10.4 was the first Intel release, 10.3 was still all PPC, we are talking 2003 here) with
>
> ld="env MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}"
>
> See https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html for the description of the binary compatibility settings.
>
> (In that macports ticket also other matters are discussed, but since I found experts, I asked them about the deployment target setting.)
>
> What happens is something on a lower deployment target attempts to run a binary built on a higher deployment target, it will simply fail to run at all.
>
> For some of previous discussions (as in: please read them to avoid repeating the same discussions too much) see
>
> https://rt.perl.org/Ticket/Display.html?id=117433
>
> https://rt.perl.org/Ticket/Display.html?id=123985
>
> http://markmail.org/message/yoxutk5dfbu4r6ga#query:+page:1+mid:n5cbiz2dmpfmrwp2+state:results
>
> I am boldly CCing some of the people from the above.
>
> Previously, I have leaned on the side of backward compatibility, in other words, doing nothing.
>
> But now I'm starting to lean towards doing ... something. The 10.3 is definitely getting old. In the macports ticket they suggest 10.4 at the minimum if PPC is really still a goal. But 10.6 preferably. Or if we want more modern nice linker things, 10.7. (I am guessing there might also be some nicer compiler things, not just linker.)
>
> So if compiled without anything, one gets whatever target the current tool chain uses. (And that then won't run on older boxes.)
>
> How about something like following: if the person configuring somehow explicitly asks for an older deployment target, then and only then we set the linker to that target. If they do not, we will compile without any specific setting, getting all the modernity benefits.
>
> How the explicit asking might work? I have two ideas: (1) if there is environment variable MACOSX_DEPLOYMENT_TARGET set, use that ... this is kind of blindingly obvious extension of the old way (2) Configure option/variable, -Dusesomething -- though I'm a little leery of a very OS-specific Configure option.
>
I've been thinking about this as well since I'm getting linker
warnings about a mismatch between what the compiler specifies (which
seems to default to whatever it's currently running on) and the
explicit link target. One of the things I discovered is that 10.3 is
simply invalid if any Intel architecture is targeted. This from
reading AvailabiltyMacros.h at
<http://www.opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/AvailabilityMacros.h>.
The linker apparently ignores 10.3 and pretends you asked for 10.4, so
it's currently "only a warning" but could get worse.
My only revision to your suggestion #1 is to leave things alone when
the build system is oldish, say 10.4 or earlier. Otherwise target one
or two "landing places." So, for example, when building on 10.5
through 10.7, target 10.5; when building on 10.8 or later, target
10.7. But override those defaults when MACOSX_DEPLOYMENT_TARGET is
set.
Also, I think for systems that can (10.5+?), we should be using
-mmacosx-version-min and adding it to both ccflags and ldflags and
only read from the environment for an override value rather than
setting it. I've been doing some of the same reading you've been
doing and I got the impression that compiling for latest greatest but
linking for truly ancient doesn't necessarily give you a binary that
can really run on that ancient target given that you've linked against
stubs for routines that may not exist there. I think the only reason
we don't specify a target for the compiler is that back in the 10.3
era it only made a difference for the linker, but now it can make a
difference for both, so I think both should be specified consistently.
Having all this, I'm really not an expert in Apple build systems, so
if there is anyone listening in who is, please correct me if I've got
something wrong.
Thread Previous
|
Thread Next