Skip Menu |
Report information
Id: 126360
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: jhi <jhi [at] iki.fi>
Cc: jkeenan <jkeenan [at] cpan.org>
LeonT <fawaka [at] gmail.com>
mark.dootson [at] znix.com
rjbs <rjbs [at] cpan.org>
timbo <Tim.Bunce [at] pobox.com>
venture37 [at] geeklan.co.uk
AdminCc:

Operating System: darwin
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: MACOSX_DEPLOYMENT_TARGET
CC: Tim.Bunce [...] pobox.com, fawaka [...] gmail.com, mark.dootson [...] znix.com, venture37 [...] geeklan.co.uk, jkeenan [...] cpan.org, rjbs [...] cpan.org
Download (untitled) / with headers
text/plain 2.3k
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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.8k
On Wed Oct 14 13:45:01 2015, jhi wrote: Show quoted text
> 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.
Jarkko: How would this patch: https://rt.perl.org/Ticket/Attachment/1332434/711615/0002-very-first-step-to-tidy-up-mess-around-sdk-to-use.patch ... which is from https://rt.perl.org/Ticket/Display.html?id=123831 and which Tony Cook and I were discussing last night in #p5p affect this issue? Thank you very much. -- James E Keenan (jkeenan@cpan.org)
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Date: Wed, 14 Oct 2015 17:23:00 -0500
CC: bugs-bitbucket [...] rt.perl.org
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 4.4k
On Wed, Oct 14, 2015 at 3:45 PM, Jarkko Hietaniemi <perlbug-followup@perl.org> wrote: Show quoted text
> # 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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 817b
Show quoted text
> Jarkko: > > How would this patch: > > https://rt.perl.org/Ticket/Attachment/1332434/711615/0002-very-first- > step-to-tidy-up-mess-around-sdk-to-use.patch > > ... which is from https://rt.perl.org/Ticket/Display.html?id=123831
Missed that one... Show quoted text
> and which Tony Cook and I were discussing last night in #p5p affect > this issue?
The above-suggested patch is implicit, I suggested explicit (the configurer deciding). But I don't mind either way. Binding together the installed SDK and the deployment target is definitely a possibility. At least it would be better than the current "link like it's 2003" state of things. With that patch one could also build a backward compatible version, by hinting -Dld="env MACOSX_DEPLOYMENT_TARGET=whatever $cc'", though that's quite ugly... Show quoted text
> Thank you very much.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
On Wed Oct 14 15:24:24 2015, jhi wrote: Show quoted text
> > Jarkko: > > > > How would this patch: > > > > https://rt.perl.org/Ticket/Attachment/1332434/711615/0002-very-first- > > step-to-tidy-up-mess-around-sdk-to-use.patch > > > > ... which is from https://rt.perl.org/Ticket/Display.html?id=123831
> > Missed that one... >
> > and which Tony Cook and I were discussing last night in #p5p affect > > this issue?
> > The above-suggested patch is implicit, I suggested explicit (the > configurer deciding). But I don't mind either way. Binding together > the installed SDK and the deployment target is definitely a > possibility. At least it would be better than the current "link like > it's 2003" state of things. > > With that patch one could also build a backward compatible version, by > hinting -Dld="env MACOSX_DEPLOYMENT_TARGET=whatever $cc'", though > that's quite ugly... >
> > Thank you very much.
I think as reasonable first step we could just apply Jens' patch. Second minor tweak would be to have the minimum to be 10.4, instead of 10.3 (as suggested by the macports guys). Then we can look into additional cc/ld options like what Craig described. And maybe also add the env $MACOSX_DEPLOYMENT_TARGET trick to make it easier to hint the minimum, if one wants. Though as Craig noted, compiling for ancient releases might not actually even work that well. The thing is, we need older OS X boxes to be able to test this. Anyone still run PPC?
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Wed Oct 14 15:38:59 2015, jhi wrote: Show quoted text
> On Wed Oct 14 15:24:24 2015, jhi wrote:
> > > Jarkko: > > > > > > How would this patch: > > > > > > https://rt.perl.org/Ticket/Attachment/1332434/711615/0002-very- > > > first- > > > step-to-tidy-up-mess-around-sdk-to-use.patch > > > > > > ... which is from https://rt.perl.org/Ticket/Display.html?id=123831
> > > > Missed that one... > >
> > > and which Tony Cook and I were discussing last night in #p5p affect > > > this issue?
> > > > The above-suggested patch is implicit, I suggested explicit (the > > configurer deciding). But I don't mind either way. Binding together > > the installed SDK and the deployment target is definitely a > > possibility. At least it would be better than the current "link like > > it's 2003" state of things. > > > > With that patch one could also build a backward compatible version, > > by > > hinting -Dld="env MACOSX_DEPLOYMENT_TARGET=whatever $cc'", though > > that's quite ugly... > >
> > > Thank you very much.
> > I think as reasonable first step we could just apply Jens' patch. >
Which I tested successfully last night on Darwin/PPC Mac OS X version 10.4.11. Show quoted text
> Second minor tweak would be to have the minimum to be 10.4, instead of > 10.3 (as suggested by the macports guys). > > Then we can look into additional cc/ld options like what Craig > described. > > And maybe also add the env $MACOSX_DEPLOYMENT_TARGET trick to make it > easier to hint the minimum, if one wants. Though as Craig noted, > compiling for ancient releases might not actually even work that well. > > The thing is, we need older OS X boxes to be able to test this. > Anyone still run PPC?
Yo! -- James E Keenan (jkeenan@cpan.org)
Date: Wed, 14 Oct 2015 21:53:26 -0500
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Craig Berry via RT <perlbug-followup [...] perl.org>
CC: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 967b
On Wed, Oct 14, 2015 at 5:39 PM, Jarkko Hietaniemi via RT <perlbug-followup@perl.org> wrote: Show quoted text
> I think as reasonable first step we could just apply Jens' patch.
I like the idea of detecting what the environment can do and deciding based on that, but I see a potential problem with this particular approach, assuming I've read the patch at https://rt.perl.org/Public/Ticket/Attachment/1332434/711615/0002-very-first-step-to-tidy-up-mess-around-sdk-to-use.patch correctly. It's doing $ xcrun --show-sdk-version 10.11 and using the output of that to set the deployment target. I happen to be on OS X 10.10 but have installed XCode 7.0.1, which has a base SDK of 10.11. If I use 10.11 as the deployment target on my 10.10 system, I would not be making binaries I could even run on my current system would I? To me the base SDK looks more like the maximum features you can include and is not really suitable for selecting the minimum system you want to target.
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Date: Wed, 14 Oct 2015 22:26:14 -0500
CC: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Craig Berry via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 657b
On Wed, Oct 14, 2015 at 9:53 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote: Show quoted text
> On Wed, Oct 14, 2015 at 5:39 PM, Jarkko Hietaniemi via RT > <perlbug-followup@perl.org> wrote: >
>> I think as reasonable first step we could just apply Jens' patch.
Show quoted text
> If I use 10.11 as the deployment target on my > 10.10 system, I would not be making binaries I could even run on my > current system would I?
It did build and pass tests, but to me it's still weird to be specifying a minimum version of 10.11 on a 10.10 system: $ ./perl -Ilib -V:ld ld='env MACOSX_DEPLOYMENT_TARGET=10.11 cc'; $ sw_vers ProductName: Mac OS X ProductVersion: 10.10.5 BuildVersion: 14F27
RT-Send-CC: perl5-porters [...] perl.org
On Wed Oct 14 19:53:57 2015, craig.a.berry@gmail.com wrote: Show quoted text
> On Wed, Oct 14, 2015 at 5:39 PM, Jarkko Hietaniemi via RT > <perlbug-followup@perl.org> wrote: >
> > I think as reasonable first step we could just apply Jens' patch.
> > I like the idea of detecting what the environment can do and deciding > based on that, but I see a potential problem with this particular > approach, assuming I've read the patch at > > https://rt.perl.org/Public/Ticket/Attachment/1332434/711615/0002-very- > first-step-to-tidy-up-mess-around-sdk-to-use.patch > > correctly. > > It's doing > > $ xcrun --show-sdk-version > 10.11 > > and using the output of that to set the deployment target. > > I happen to be on OS X 10.10 but have installed XCode 7.0.1, which has > a base SDK of 10.11. If I use 10.11 as the deployment target on my > 10.10 system, I would not be making binaries I could even run on my > current system would I? To me the base SDK looks more like the > maximum features you can include and is not really suitable for > selecting the minimum system you want to target.
But this is a problem created by Apple, is it not? They released a SDK that works at k+1, while also being able to be installed and run at k? I think we also should be safe to assume that within such a small window the binaries will be also (really) backward-compatible. On the selection of the target level we have at least two options: (a) Jens' patch which used the installed SDK to divine a safe (max) level (b) hardcode something to the hints (e.g. 10.4 if we want to be superconservative, that would still include PPC, or 10.4 if we are in a PPC; and then 10.7 for *x86*) The upside of (a) is that it will automagically be future-proof. The upside of (b) is that it is predictable and stable. The downside of (a) is ... mmm, maybe if Apple at some point really breaks the bincompat between k and k+1, introducing a SDK that really shouldn't be used at k? Too crazy? The downside of (b) is that at some point in future the 10.7 will eventually become too dusty, and needs updating.
Date: Thu, 15 Oct 2015 08:46:45 -0500
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
CC: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Craig Berry via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.9k
On Thu, Oct 15, 2015 at 5:57 AM, Jarkko Hietaniemi via RT <perlbug-followup@perl.org> wrote: Show quoted text
>> I happen to be on OS X 10.10 but have installed XCode 7.0.1, which has >> a base SDK of 10.11. If I use 10.11 as the deployment target on my >> 10.10 system, I would not be making binaries I could even run on my >> current system would I? To me the base SDK looks more like the >> maximum features you can include and is not really suitable for >> selecting the minimum system you want to target.
> > But this is a problem created by Apple, is it not? They released a SDK > that works at k+1, while also being able to be installed and run at k? > I think we also should be safe to assume that within such a small > window the binaries will be also (really) backward-compatible.
I don't know, but I suspect it would require someone building extensions to have the same SDK. Show quoted text
> On the selection of the target level we have at least two options: > (a) Jens' patch which used the installed SDK to divine a safe (max) level > (b) hardcode something to the hints (e.g. 10.4 if we want to be > superconservative, that would still include PPC, or 10.4 if we are > in a PPC; and then 10.7 for *x86*) > > The upside of (a) is that it will automagically be future-proof. > > The upside of (b) is that it is predictable and stable. > > The downside of (a) is ... mmm, maybe if Apple at some point > really breaks the bincompat between k and k+1, introducing a SDK > that really shouldn't be used at k? Too crazy? > > The downside of (b) is that at some point in future the 10.7 > will eventually become too dusty, and needs updating.
I'm fine with doing something simple that gets us away from the hard-coded 10.3. A variant of (a) would be to do what Apple does and target the system we are building on rather than the currently-selected SDK version: <http://www.opensource.apple.com/source/perl/perl-103.40.1/5.18/fix/darwin.sh.ed> Of course they are building a Perl to distribute *with* that system, so maybe that's not appropriate for us.
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Date: Wed, 14 Oct 2015 23:43:43 +0100
To: perlbug-followup [...] perl.org
From: Sevan Janiyan <venture37 [...] geeklan.co.uk>
CC: Tim.Bunce [...] pobox.com, fawaka [...] gmail.com, jkeenan [...] cpan.org, mark.dootson [...] znix.com, rjbs [...] cpan.org
Download (untitled) / with headers
text/plain 300b
On 14/10/2015 23:38, Jarkko Hietaniemi via RT wrote: Show quoted text
> Anyone still run PPC?
Yes, I run the Mac OS X PowerPC builds of pkgsrc and can test any patches that are need on Tiger PowerPC pkgsrc currently uses the solution proposed in bug #117433 https://rt.perl.org/Public/Bug/Display.html?id=117433
From: Sevan Janiyan <venture37 [...] geeklan.co.uk>
To: perlbug-followup [...] perl.org
Date: Thu, 15 Oct 2015 15:48:46 +0100
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Download (untitled) / with headers
text/plain 1.1k
Guys, MACOSX_DEPLOYMENT_TARGET only makes sense on Leopard & prior. On Snow Leopard & onwards using clang, it's taken care of automatically. If this variable is not set, the cctools defaults to MACOSX_DEPLOYMENT_TARGET to OS X 10.1 for PowerPC systems & 10.4 on Intel systems. Ideally MACOSX_DEPLOYMENT_TARGET should default to 10.4 but 10.3 is actually the earliest version of OS X Perl 5 will run on correctly. Is there any reason why the patch below is not a viable solution? --- hints/darwin.sh.orig 2015-05-13 20:19:29.000000000 +0000 +++ hints/darwin.sh @@ -200,7 +200,7 @@ case "$osvers" in ldflags="${ldflags} -flat_namespace" lddlflags="${ldflags} -bundle -undefined suppress" ;; -*) +[7-9].*) # MACOSX_DEPLOYMENT_TARGET selects the minimum OS level we want to support # https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html lddlflags="${ldflags} -bundle -undefined dynamic_lookup" @@ -209,6 +209,9 @@ case "$osvers" in *) ld="env MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;; esac ;; +*) + lddlflags="${ldflags} -bundle -undefined dynamic_lookup" + ;; esac ldlibpthname='DYLD_LIBRARY_PATH';
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 899b
On Thu Oct 15 09:56:46 2015, venture37@geeklan.co.uk wrote: Show quoted text
> Guys, > MACOSX_DEPLOYMENT_TARGET only makes sense on Leopard & prior. On Snow > Leopard & onwards using clang, it's taken care of automatically. > > If this variable is not set, the cctools defaults to > MACOSX_DEPLOYMENT_TARGET to OS X 10.1 for PowerPC systems & 10.4 on > Intel systems.
I am afraid that I cannot reach the same conclusion from either Apple's documentation on this, or from the Internet hive mind. The 10.4 and 10.7 seem to be the _defaults_ if nothing else is set. Setting explicit MACOSX_DEPLOYMENT_TARGET seems to very much being used (and causing similar problems) in other opensource projects, too. See the macports ticket mentioned in the beginning of this ticket. Show quoted text
> Ideally MACOSX_DEPLOYMENT_TARGET should default to 10.4 but 10.3 is > actually the earliest version of OS X Perl 5 will run on correctly.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
Also, I don't know whether assuming the cctools or the clang from macports is a good assumption to make. I can install gcc from macports and build with that. Or icc. Thinking about this some more... (1) if we are in a PPC system, we have two options: 10.3 or 10.4. The 10.3 is what we have been "always" using; 10.4 is the first with Intel support. (*). The 10.4 is also what the macports guys recommended for PPC. So I would say 10.4 here. (2) if we are in an x86_64/ia-32, we have an obvious max (what the SDK supports), and an obvious min (what the OS itself is). I'm coming to the opinion of using the OS level (as opposed to Jens' patch): it looks less odd (as pointed out by Craig), and if a SDK works at the OS level, it should be able to produce binaries that work at the OS level, no? (3) fallback default, if nothing else works, on x86_64/ia-32 is - at this moment - 10.7 (macports guys) (4) we have to consider two kinds of users, at least: (4a) those building for this and later (as far as Apple's bincompat stretches to the future) -- bleadperl smokers here (4b) those building for some earlier target level (again, Apple's bincompat strechiness, to the past) -- system integrators here Theoretically, one could also build for some future level, if the SDK allows, but I think this use is rather far-fetched to bother considering. For the (4b) we would need to have a way to enforce building for an older level. I would suggest the env $MACOSX_DEPLOYMENT_LEVEL. (*) According to Wikipedia: PPC 10.0 until 10.5.8; ia-32 10.4.4 until now; x86_64 10.4.7 until now (**) I use it here to mean either x86_64 or ia-32
CC: Tim.Bunce [...] pobox.com, fawaka [...] gmail.com, jkeenan [...] cpan.org, mark.dootson [...] znix.com, rjbs [...] cpan.org
To: perlbug-followup [...] perl.org
From: Sevan Janiyan <venture37 [...] geeklan.co.uk>
Date: Thu, 15 Oct 2015 19:04:26 +0100
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Download (untitled) / with headers
text/plain 2.2k
Hi, On 15/10/2015 18:19, Jarkko Hietaniemi via RT wrote: Show quoted text
> I am afraid that I cannot reach the same conclusion from either > Apple's documentation on this, or from the Internet hive mind. The > 10.4 and 10.7 seem to be the _defaults_ if nothing else is set.
See the ld(1) man page. From 10.4.11 with XCode 2.5 installed ========================== -macosx_version_min version This overrides the MACOSX_DEPLOYMENT_TARGET environment variable (see below). Unlike other linker options, this one may be specified multiple times; only the last occurrence is effective. The following environment variable is used to control the use of incompatible features in the output with respect to Mac OS X releases. MACOSX_DEPLOYMENT_TARGET This is set to indicate the oldest Mac OS X version that that the output is to be used on. When this is set to a release that is older than the current release features that are incompatible with that release will be disabled. If a feature is seen in the input that can't be in the output due to this setting a warning is issued. The current allowable values for this are 10.1, 10.2 10.3, and 10.4 with the default being 10.4 for the i386 architecture and 10.1 for all other architectures. ========================== If you build on a modern version of OS X with the patch I linked to earlier, you will not have any issue with MACOSX_DEPLOYMENT_TARGET on modern systems and will retain backwards compatibility with 10.3 to 10.5 on PowerPC systems. The wikipedia Mach-O binary format explains the issue. https://en.wikipedia.org/wiki/Mach-O#Minimum_Mac_OS_X_version Show quoted text
> Setting explicit MACOSX_DEPLOYMENT_TARGET seems to very much being > used (and causing similar problems) in other opensource projects, > too.
But is that a relic from the past being carried forward or are you explicitly setting that because you need ABI compatibility with a specific version. It does not need to be set on modern versions of OS X (10.6 and newer). The patch I posted previously is used to build Perl on OS X 10.4.11/PowerPC, 10.6 & 10.11 intel without issue for the past 11 months. Show quoted text
> See the macports ticket mentioned in the beginning of this ticket.
I looked, if you only set MACOSX_DEPLOYMENT_TARGET for legacy systems, it is not a problem. Perl bug #117433 is worth looking at (which remains open by the way). Sevan
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 564b
Attached is an attempt at amalgamating some of the suggested behaviours: (1) for OSX 10.6 or later, do not use the MACOSX_DEPLOYMENT_TARGET (for earlier, no changes) like in https://rt.perl.org/Public/Bug/Display.html?id=117433 (2) for all OS X versions, set -mmacosx-version-min in ccflags and ldflags, either from (2a) env var $MACOSX_DEPLOYMENT_TARGET (2b) the OS X release from sw_vers (not $osvers, that's the kernel version) (Most notable omission is NOT using the SDK version.) Please test profusely, especially in older, especially in PPC.
Subject: 0001-OS-X-versioning-dance.patch
From 669b884a5b87b37a98e9784b38e74f20152c43b1 Mon Sep 17 00:00:00 2001 From: Jarkko Hietaniemi <jhi@iki.fi> Date: Thu, 15 Oct 2015 20:33:59 -0400 Subject: [PATCH] OS X versioning dance. Note the difference between the OS X version (10.X) and the kernel version, it's the latter that Configure knows as $osvers. Adding a cross-reference table for these versions rom the NetBSD project. For OS X 10.6 or above, do not any more use the MACOSX_DEPLOYMENT_TARGET, the toolchains should work fine without. Until now the deployment target was hardwired to 10.3. This logic comes from https://rt.perl.org/Public/Bug/Display.html?id=117433 For OS X releases from 10.3 until 10.5, no change, still using the MACOSX_DEPLOYMENT_TARGET=10.3 for linking. For OS X releases before 10.3, no change, still not using the MACOSX_DEPLOYMENT_TARGET=10.3. New: always add -mmacosx-version-min to ccflags and ldflags from the env var $MACOSX_DEPLOYMENT_TARGET, if set. If the var is not set, set the min from the OS X version, from sw_vers(1). Setting the var should become handy for people building and packaging Perl for earlier OS X versions. We assume that the toolchain/SDK installed to system will be able to build for the requested minimum versions and deployment targets, or if it is not, it should properly warn or die. --- hints/darwin.sh | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 99 insertions(+), 7 deletions(-) diff --git a/hints/darwin.sh b/hints/darwin.sh index 81cdcff..7d62e7a 100644 --- a/hints/darwin.sh +++ b/hints/darwin.sh @@ -186,30 +186,122 @@ case "$ld" in ;; esac +# From http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/mk/platform/Darwin.mk +# +# OS, Kernel, Xcode Version +# Note that Xcode gets updates on older systems sometimes. +# pkgsrc generally expects that the most up-to-date xcode available for +# an OS version is installed +# +# Codename OS Kernel Xcode +# Cheetah 10.0.x 1.3.1 +# Puma 10.1 1.4.1 +# 10.1.x 5.x.y +# Jaguar 10.2.x 6.x.y +# Panther 10.3.x 7.x.y +# Tiger 10.4.x 8.x.y 2.x (gcc 4.0, 4.0.1 from 2.2) +# Leopard 10.5.x 9.x.y 3.x (gcc 4.0.1, 4.0.1 and 4.2.1 from 3.1) +# Snow Leopard 10.6.x 10.x.y 3.2+ (gcc 4.0.1 and 4.2.1) +# Lion 10.7.x 11.x.y 4.1 (llvm gcc 4.2.1) +# Mountain Lion 10.8.x 12.x.y 4.5 (llvm gcc 4.2.1) +# Mavericks 10.9.x 13.x.y 6 (llvm clang 6.0) +# Yosemite 10.10.x 14.x.y 6 (llvm clang 6.0) +# El Capitan 10.11.x 15.x.y 7 (llvm clang 7.0) + +# MACOSX_DEPLOYMENT_TARGET selects the minimum OS level we want to support +# +# It is needed for OS releases before 10.6. +# +# https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html +# +# If it is set, we also propagate its value to ccflags and ldflags +# using the -mmacosx-version-min flag. If it is not set, we use +# the OS X release as the min value for the flag. + # Perl bundles do not expect two-level namespace, added in Darwin 1.4. # But starting from perl 5.8.1/Darwin 7 the default is the two-level. -case "$osvers" in -1.[0-3].*) +case "$osvers" in # Note: osvers is the kernel version, not the 10.x +1.[0-3].*) # OS X 10.0.x lddlflags="${ldflags} -bundle -undefined suppress" ;; -1.*) +1.*) # OS X 10.1 ldflags="${ldflags} -flat_namespace" lddlflags="${ldflags} -bundle -undefined suppress" ;; -[2-6].*) +[2-6].*) # OS X 10.1.x - 10.2.x (though [2-4] never existed publicly) ldflags="${ldflags} -flat_namespace" lddlflags="${ldflags} -bundle -undefined suppress" ;; -*) - # MACOSX_DEPLOYMENT_TARGET selects the minimum OS level we want to support - # https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html +[7-9].*) # OS X 10.3.x - 10.5.x lddlflags="${ldflags} -bundle -undefined dynamic_lookup" case "$ld" in *MACOSX_DEVELOPMENT_TARGET*) ;; *) ld="env MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;; esac ;; +*) # OS X 10.6.x - current + # The MACOSX_DEPLOYMENT_TARGET is not needed, + # but the -mmacosx-version-min option is always used. + lddlflags="${ldflags} -bundle -undefined dynamic_lookup" + ;; esac + +# Adds "-mmacosx-version-min=$2" to "$1" unless it already is there. +add_macosx_version_min () { + local v + eval "v=\$$1" + case " $v " in + *"-mmacosx-version-min"*) + echo "NOT adding -mmacosx-version-min=$2 to $1 ($v)" >&4 + ;; + *) echo "Adding -mmacosx-version-min=$2 to $1" >&4 + eval "$1='$v -mmacosx-version-min=$2'" + ;; + esac +} + +case "$MACOSX_DEPLOYMENT_TARGET" in +10.*) + add_macosx_version_min ccflags $MACOSX_DEPLOYMENT_TARGET + add_macosx_version_min ldflags $MACOSX_DEPLOYMENT_TARGET + ;; +'') + # Empty MACOSX_DEPLOYMENT_TARGET is okay. + ;; +*) + cat <<EOM >&4 + +*** Unexpected MACOSX_DEPLOYMENT_TARGET=$MACOSX_DEPLOYMENT_TARGET +*** +*** Please either set it to 10.something, or to empty. + +EOM + exit 1 + ;; +esac + +# Keep the prodvers leading whitespace (Configure magic). +# Cannot use $osvers here since that is the kernel version. +# sw_vers output what we want +# "ProductVersion: 10.10.5" "10.10" +# "ProductVersion: 10.11" "10.11" + prodvers=`sw_vers|awk '/^ProductVersion:/{print $2}'|awk -F. '{print $1"."$2}'` +case "$prodvers" in +10.*) + add_macosx_version_min ccflags $prodvers + add_macosx_version_min ldflags $prodvers + ;; +*) + cat <<EOM >&4 + +*** Unexpected product version $prodvers. +*** +*** Try running sw_vers and see what its ProductVersion says. + +EOM + exit 1 +esac + ldlibpthname='DYLD_LIBRARY_PATH'; # useshrplib=true results in much slower startup times. -- 2.6.0
RT-Send-CC: perl5-porters [...] perl.org
Craig Berry found problems with my latest patch, here's a fixed one from him.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 136b
On Fri Oct 16 07:41:35 2015, jhi wrote: Show quoted text
> Craig Berry found problems with my latest patch, here's a fixed one > from him.
For realz.
Subject: 0001-OS-X-versioning-dance.patch
From 903369ea8cd1e0ea4ebf3a4b751c968720266c7b Mon Sep 17 00:00:00 2001 From: Jarkko Hietaniemi <jhi@iki.fi> Date: Thu, 15 Oct 2015 20:33:59 -0400 Subject: [PATCH] OS X versioning dance. Note the difference between the OS X version (10.X) and the kernel version, it's the latter that Configure knows as $osvers. Adding a cross-reference table for these versions rom the NetBSD project. For OS X 10.6 or above, do not any more use the MACOSX_DEPLOYMENT_TARGET, the toolchains should work fine without. Until now the deployment target was hardwired to 10.3. This logic comes from https://rt.perl.org/Public/Bug/Display.html?id=117433 For OS X releases from 10.3 until 10.5, no change, still using the MACOSX_DEPLOYMENT_TARGET=10.3 for linking. For OS X releases before 10.3, no change, still not using the MACOSX_DEPLOYMENT_TARGET=10.3. New: always add -mmacosx-version-min to ccflags and ldflags from the env var $MACOSX_DEPLOYMENT_TARGET, if set. If the var is not set, set the min from the OS X version, from sw_vers(1). Setting the var should become handy for people building and packaging Perl for earlier OS X versions. We assume that the toolchain/SDK installed to system will be able to build for the requested minimum versions and deployment targets, or if it is not, it should properly warn or die. --- hints/darwin.sh | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 102 insertions(+), 7 deletions(-) diff --git a/hints/darwin.sh b/hints/darwin.sh index 81cdcff..956e80f 100644 --- a/hints/darwin.sh +++ b/hints/darwin.sh @@ -186,30 +186,125 @@ case "$ld" in ;; esac +# From http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/mk/platform/Darwin.mk +# +# OS, Kernel, Xcode Version +# Note that Xcode gets updates on older systems sometimes. +# pkgsrc generally expects that the most up-to-date xcode available for +# an OS version is installed +# +# Codename OS Kernel Xcode +# Cheetah 10.0.x 1.3.1 +# Puma 10.1 1.4.1 +# 10.1.x 5.x.y +# Jaguar 10.2.x 6.x.y +# Panther 10.3.x 7.x.y +# Tiger 10.4.x 8.x.y 2.x (gcc 4.0, 4.0.1 from 2.2) +# Leopard 10.5.x 9.x.y 3.x (gcc 4.0.1, 4.0.1 and 4.2.1 from 3.1) +# Snow Leopard 10.6.x 10.x.y 3.2+ (gcc 4.0.1 and 4.2.1) +# Lion 10.7.x 11.x.y 4.1 (llvm gcc 4.2.1) +# Mountain Lion 10.8.x 12.x.y 4.5 (llvm gcc 4.2.1) +# Mavericks 10.9.x 13.x.y 6 (llvm clang 6.0) +# Yosemite 10.10.x 14.x.y 6 (llvm clang 6.0) +# El Capitan 10.11.x 15.x.y 7 (llvm clang 7.0) + +# MACOSX_DEPLOYMENT_TARGET selects the minimum OS level we want to support +# +# It is needed for OS releases before 10.6. +# +# https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html +# +# If it is set, we also propagate its value to ccflags and ldflags +# using the -mmacosx-version-min flag. If it is not set, we use +# the OS X release as the min value for the flag. + +# Adds "-mmacosx-version-min=$2" to "$1" unless it already is there. +add_macosx_version_min () { + local v + eval "v=\$$1" + case " $v " in + *"-mmacosx-version-min"*) + echo "NOT adding -mmacosx-version-min=$2 to $1 ($v)" >&4 + ;; + *) echo "Adding -mmacosx-version-min=$2 to $1" >&4 + eval "$1='$v -mmacosx-version-min=$2'" + ;; + esac +} + # Perl bundles do not expect two-level namespace, added in Darwin 1.4. # But starting from perl 5.8.1/Darwin 7 the default is the two-level. -case "$osvers" in -1.[0-3].*) +case "$osvers" in # Note: osvers is the kernel version, not the 10.x +1.[0-3].*) # OS X 10.0.x lddlflags="${ldflags} -bundle -undefined suppress" ;; -1.*) +1.*) # OS X 10.1 ldflags="${ldflags} -flat_namespace" lddlflags="${ldflags} -bundle -undefined suppress" ;; -[2-6].*) +[2-6].*) # OS X 10.1.x - 10.2.x (though [2-4] never existed publicly) ldflags="${ldflags} -flat_namespace" lddlflags="${ldflags} -bundle -undefined suppress" ;; -*) - # MACOSX_DEPLOYMENT_TARGET selects the minimum OS level we want to support - # https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html +[7-9].*) # OS X 10.3.x - 10.5.x lddlflags="${ldflags} -bundle -undefined dynamic_lookup" case "$ld" in *MACOSX_DEVELOPMENT_TARGET*) ;; *) ld="env MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;; esac ;; +*) # OS X 10.6.x - current + # The MACOSX_DEPLOYMENT_TARGET is not needed, + # but the -mmacosx-version-min option is always used. + + # We now use MACOSX_DEPLOYMENT_TARGET, if set, as an override by + # capturing its value and adding it to the flags. + case "$MACOSX_DEPLOYMENT_TARGET" in + 10.*) + add_macosx_version_min ccflags $MACOSX_DEPLOYMENT_TARGET + add_macosx_version_min ldflags $MACOSX_DEPLOYMENT_TARGET + ;; + '') + # Empty MACOSX_DEPLOYMENT_TARGET is okay. + ;; + *) + cat <<EOM >&4 + +*** Unexpected MACOSX_DEPLOYMENT_TARGET=$MACOSX_DEPLOYMENT_TARGET +*** +*** Please either set it to 10.something, or to empty. + +EOM + exit 1 + ;; + esac + + # Keep the prodvers leading whitespace (Configure magic). + # Cannot use $osvers here since that is the kernel version. + # sw_vers output what we want + # "ProductVersion: 10.10.5" "10.10" + # "ProductVersion: 10.11" "10.11" + prodvers=`sw_vers|awk '/^ProductVersion:/{print $2}'|awk -F. '{print $1"."$2}'` + case "$prodvers" in + 10.*) + add_macosx_version_min ccflags $prodvers + add_macosx_version_min ldflags $prodvers + ;; + *) + cat <<EOM >&4 + +*** Unexpected product version $prodvers. +*** +*** Try running sw_vers and see what its ProductVersion says. + +EOM + exit 1 + esac + + lddlflags="${ldflags} -bundle -undefined dynamic_lookup" + ;; esac + ldlibpthname='DYLD_LIBRARY_PATH'; # useshrplib=true results in much slower startup times. -- 2.6.0
CC: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>, bugs-bitbucket [...] rt.perl.org
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
From: "David E. Wheeler" <david [...] justatheory.com>
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Date: Fri, 16 Oct 2015 09:18:05 -0700
Download (untitled) / with headers
text/plain 646b
On Oct 14, 2015, at 3:23 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote: Show quoted text
> 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.
In this answer to an SO question I posted: http://stackoverflow.com/a/32284231/79202 The suggestion is to dynamically set MACOSX_DEPLOYMENT_TARGET in `hints/darwin.sh`. Is there any reason why it shouldn’t just be set to the version of the OS on which it’s being built? There’s also some discussion in this issue in RT #123985. https://rt.perl.org/Public/Bug/Display.html?id=123985# David
Download smime.p7s
application/pkcs7-signature 4k

Message body not shown because it is not plain text.

From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Craig Berry via RT <perlbug-followup [...] perl.org>
CC: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Date: Fri, 16 Oct 2015 11:19:39 -0500
Download (untitled) / with headers
text/plain 581b
On Fri, Oct 16, 2015 at 8:36 AM, Jarkko Hietaniemi via RT <perlbug-followup@perl.org> wrote: Show quoted text
> > Please test profusely, especially in older, especially in PPC.
On the following system doing a default configuration and git clean -xdf in between, the config.sh is identical before and after this patch (except for configuration timestamp). In other words, we've successfully preserved existing behavior for this older PPC Mac running 10.5.8. % sw_vers ProductName: Mac OS X ProductVersion: 10.5.8 BuildVersion: 9L30 % cc -version powerpc-apple-darwin9-gcc-4.0.1: no input files
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 535b
Show quoted text
> > In this answer to an SO question I posted: > > http://stackoverflow.com/a/32284231/79202 > > The suggestion is to dynamically set MACOSX_DEPLOYMENT_TARGET in > `hints/darwin.sh`. Is there any reason why it shouldn’t just be set to > the version of the OS on which it’s being built?
My understanding from the discussion so far is that 10.6 and after it should be not be necessary at all. Show quoted text
> There’s also some discussion in this issue in RT #123985. > > https://rt.perl.org/Public/Bug/Display.html?id=123985# > > David
To: "David E. Wheeler" <david [...] justatheory.com>
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
CC: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>, bugs-bitbucket [...] rt.perl.org
Date: Fri, 16 Oct 2015 11:48:25 -0500
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Download (untitled) / with headers
text/plain 1.2k
On Fri, Oct 16, 2015 at 11:18 AM, David E. Wheeler <david@justatheory.com> wrote: Show quoted text
> In this answer to an SO question I posted: > > http://stackoverflow.com/a/32284231/79202 > > The suggestion is to dynamically set MACOSX_DEPLOYMENT_TARGET in `hints/darwin.sh`. Is there any reason why it shouldn’t just be set to the version of the OS on which it’s being built?
That's kinda sorta what Jarkko's latest patch does when building on 10.6 or later, except instead of using the environment setting we use the -mmacosx-version-min command-line switch, adding it to compiler and linker flags. The default is to use the OS version we're building on as the value for that switch, but if MACOSX_DEPLOYMENT_TARGET is set in the environment, we capture its value and use that instead. In either case (overridden from the environment or not) the -mmacosx-version-min settings in the flags will produce a consistent build target for extensions built against that perl later on other systems that are on different OS versions and/or do not have the environment setting. Current docs define the environment setting as follows: MACOSX_DEPLOYMENT_TARGET If -mmacosx-version-min is unspecified, the default deployment target is read from this environment variable. This option only affects darwin targets.
CC: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>, bugs-bitbucket [...] rt.perl.org
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
From: "David E. Wheeler" <david [...] justatheory.com>
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Date: Fri, 16 Oct 2015 12:48:55 -0700
Download (untitled) / with headers
text/plain 903b
On Oct 16, 2015, at 9:48 AM, Craig A. Berry <craig.a.berry@gmail.com> wrote: Show quoted text
> That's kinda sorta what Jarkko's latest patch does when building on > 10.6 or later, except instead of using the environment setting we use > the -mmacosx-version-min command-line switch, adding it to compiler > and linker flags. The default is to use the OS version we're building > on as the value for that switch, but if MACOSX_DEPLOYMENT_TARGET is > set in the environment, we capture its value and use that instead.
Yeah, that sounds like a great solution. Show quoted text
> In either case (overridden from the environment or not) the > -mmacosx-version-min settings in the flags will produce a consistent > build target for extensions built against that perl later on other > systems that are on different OS versions and/or do not have the > environment setting.
Which is even better than what I had been assuming. Best, David
Download smime.p7s
application/pkcs7-signature 4k

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
I now went ahead and pushed the change as 53d1d41c.
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
To: Jarkko Hietaniemi via RT <perlbug-followup [...] perl.org>
CC: ;, perl5-porters [...] perl.org
Date: Sat, 17 Oct 2015 21:42:00 -0400
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 479b
* Jarkko Hietaniemi via RT <perlbug-followup@perl.org> [2015-10-16T16:48:43] Show quoted text
> I now went ahead and pushed the change as 53d1d41c.
Thanks for forging ahead on this. I was a bit worried because I didn't see the problems in https://rt.perl.org/Public/Bug/Display.html?id=123985#txn-1363511 discussed, and it seemed like they'd be sure to come up... but building blead does not show the changes in behavior warned about from what I could see. So, great! Thanks again. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
CC: Jarkko Hietaniemi via RT <perlbug-followup [...] perl.org>, "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Date: Sat, 17 Oct 2015 21:23:52 -0500
Download (untitled) / with headers
text/plain 1.6k
On Sat, Oct 17, 2015 at 8:42 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: Show quoted text
> * Jarkko Hietaniemi via RT <perlbug-followup@perl.org> [2015-10-16T16:48:43]
>> I now went ahead and pushed the change as 53d1d41c.
> > Thanks for forging ahead on this. I was a bit worried because I didn't see the > problems in https://rt.perl.org/Public/Bug/Display.html?id=123985#txn-1363511 > discussed, and it seemed like they'd be sure to come up... but building blead > does not show the changes in behavior warned about from what I could see.
As far as I can tell, the things about POSIX conformance and so on that David G. mentioned had to do with specifying a target for the compiler, not the linker. Until now we've never specified an explicit target for the compiler, which means it chose its own defaults, which would typically be whatever version you are running on (or whatever latest SDK you have installed). Then we turned around and told the linker to target 10.3 no matter what. This was probably the best thing to do for some range of 10.early, but has been somewhere between a little and a lot wrong for several more recent versions. Latest greatest (XCode 7.0.1) actually warns about the discrepancy between compiler target and linker target and also silently promotes a link target of 10.3 to 10.4 because that is the minimum even possible for any Intel-only version of OS X. So the new implementation applies a consistent target version to both compiler and linker flags. There should no longer be a discrepancy between compiler and linker, nor between the perl binary and extensions built against it when those extensions are built on a later OS and/or with later build tools than was the perl binary.
Date: Sat, 17 Oct 2015 22:42:00 -0400
Subject: Fwd: [perl #126360] MACOSX_DEPLOYMENT_TARGET
From: David Golden <xdg [...] xdg.me>
To: "Chris 'BinGOs' Williams" <chris [...] bingosnet.co.uk>, p5p <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 548b
Pinging BinGOs or other motivated parties -- this also ought to go into Devel::PatchPerl when someone has a chance to do so.

---------- Forwarded message ----------
From: Jarkko Hietaniemi via RT <perlbug-followup@perl.org>
Date: Fri, Oct 16, 2015 at 4:48 PM
Subject: [perl #126360] MACOSX_DEPLOYMENT_TARGET
To:
Cc: perl5-porters@perl.org


I now went ahead and pushed the change as 53d1d41c.


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=126360



--
David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg
From: Jarkko Hietaniemi <jhi [...] iki.fi>
Date: Mon, 19 Oct 2015 22:09:48 -0400
CC: Tim.Bunce [...] pobox.com, fawaka [...] gmail.com, jkeenan [...] cpan.org, mark.dootson [...] znix.com, rjbs [...] cpan.org, venture37 [...] geeklan.co.uk
To: perlbug-followup [...] perl.org
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
Download (untitled) / with headers
text/plain 676b
On Saturday-201510-17 21:42, Ricardo Signes via RT wrote: Show quoted text
> * Jarkko Hietaniemi via RT <perlbug-followup@perl.org> [2015-10-16T16:48:43]
>> I now went ahead and pushed the change as 53d1d41c.
> > Thanks for forging ahead on this. I was a bit worried because I didn't see the > problems in https://rt.perl.org/Public/Bug/Display.html?id=123985#txn-1363511 > discussed, and it seemed like they'd be sure to come up... but building blead > does not show the changes in behavior warned about from what I could see. > > So, great! Thanks again.
Kudos on the -mmacosx-version-min belongs to Craig Berry, I was merely trying to address the MACOSX_DEPLOYMENT_TARGET silliness.
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
To: Jarkko Hietaniemi <jhi [...] iki.fi>
CC: perlbug-followup [...] perl.org
Date: Mon, 19 Oct 2015 22:42:44 -0400
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 213b
* Jarkko Hietaniemi <jhi@iki.fi> [2015-10-19T22:09:48] Show quoted text
> Kudos on the -mmacosx-version-min belongs to Craig Berry, I was > merely trying to address the MACOSX_DEPLOYMENT_TARGET silliness.
Thanks Craig! -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Jarkko Hietaniemi <jhi [...] iki.fi>
CC: Craig Berry via RT <perlbug-followup [...] perl.org>, Tim Bunce <Tim.Bunce [...] pobox.com>, Leon Timmermans <fawaka [...] gmail.com>, jkeenan [...] cpan.org, mark.dootson [...] znix.com, Ricardo Signes <rjbs [...] cpan.org>, venture37 [...] geeklan.co.uk
Date: Mon, 19 Oct 2015 21:45:00 -0500
Subject: Re: [perl #126360] MACOSX_DEPLOYMENT_TARGET
On Mon, Oct 19, 2015 at 9:09 PM, Jarkko Hietaniemi <jhi@iki.fi> wrote: Show quoted text
> On Saturday-201510-17 21:42, Ricardo Signes via RT wrote:
>> >> * Jarkko Hietaniemi via RT <perlbug-followup@perl.org> >> [2015-10-16T16:48:43]
>>> >>> I now went ahead and pushed the change as 53d1d41c.
>> >> >> Thanks for forging ahead on this. I was a bit worried because I didn't >> see the >> problems in >> https://rt.perl.org/Public/Bug/Display.html?id=123985#txn-1363511 >> discussed, and it seemed like they'd be sure to come up... but building >> blead >> does not show the changes in behavior warned about from what I could see. >> >> So, great! Thanks again.
> > > Kudos on the -mmacosx-version-min belongs to Craig Berry, I was > merely trying to address the MACOSX_DEPLOYMENT_TARGET silliness.
There are enough kudos to go around. I think Leon T. had mentioned -mmacosx-version-min in one of the tickets, and thankfully Jarkko wrote the hints changes as my unix shell scripting has never advanced beyond beginner. We learned a lot from the various tickets even if we didn't implement exactly what any of them recommended.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 331b
Dne Pet 16 Okt 2015 13:48:42 je jhi napisal: Show quoted text
> I now went ahead and pushed the change as 53d1d41c.
Thank you. I would be grateful if the change also made it back to the 5.22 branch (and ideally to 5.22.3) since the build on OS X Sierra is broken. I opened a new ticket for that (https://rt.perl.org/Ticket/Display.html?id=128980).


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org