New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MACOSX_DEPLOYMENT_TARGET #14984
Comments
From @jhiBased 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-archive.perl.org/perl5/Ticket/Display.html?id=117433 https://rt-archive.perl.org/perl5/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. |
From @jkeenanOn Wed Oct 14 13:45:01 2015, jhi wrote:
Jarkko: How would this patch: ... which is from https://rt-archive.perl.org/perl5/Ticket/Display.html?id=123831 and which Tony Cook and I were discussing last night in #p5p affect this issue? Thank you very much. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @craigberryOn Wed, Oct 14, 2015 at 3:45 PM, Jarkko Hietaniemi
I've been thinking about this as well since I'm getting linker My only revision to your suggestion #1 is to leave things alone when Also, I think for systems that can (10.5+?), we should be using Having all this, I'm really not an expert in Apple build systems, so |
From @jhi
Missed that one...
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...
|
From @jhiOn Wed Oct 14 15:24:24 2015, jhi wrote:
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? |
From @jkeenanOn Wed Oct 14 15:38:59 2015, jhi wrote:
Which I tested successfully last night on Darwin/PPC Mac OS X version 10.4.11.
Yo! -- |
From @craigberryOn Wed, Oct 14, 2015 at 5:39 PM, Jarkko Hietaniemi via RT
I like the idea of detecting what the environment can do and deciding correctly. It's doing $ xcrun --show-sdk-version 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 |
From @craigberryOn Wed, Oct 14, 2015 at 9:53 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote:
It did build and pass tests, but to me it's still weird to be $ ./perl -Ilib -V:ld |
From @jhiOn Wed Oct 14 19:53:57 2015, craig.a.berry@gmail.com wrote:
But this is a problem created by Apple, is it not? They released a SDK On the selection of the target level we have at least two options: 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 The downside of (b) is that at some point in future the 10.7 |
From @craigberryOn Thu, Oct 15, 2015 at 5:57 AM, Jarkko Hietaniemi via RT
I don't know, but I suspect it would require someone building
I'm fine with doing something simple that gets us away from the <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, |
From @sevanOn 14/10/2015 23:38, Jarkko Hietaniemi via RT wrote:
Yes, I run the Mac OS X PowerPC builds of pkgsrc and can test any pkgsrc currently uses the solution proposed in bug #117433 |
From @sevanGuys, If this variable is not set, the cctools defaults to Ideally MACOSX_DEPLOYMENT_TARGET should default to 10.4 but 10.3 is 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 |
From @jhiOn Thu Oct 15 09:56:46 2015, venture37@geeklan.co.uk wrote:
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.
|
From @jhiAlso, 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: 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 |
From @sevanHi, On 15/10/2015 18:19, Jarkko Hietaniemi via RT wrote:
See the ld(1) man page. ========================== The following environment variable is used to control the use of MACOSX_DEPLOYMENT_TARGET
|
From @jhiAttached 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) (2) for all OS X versions, set -mmacosx-version-min in ccflags and ldflags, either from (Most notable omission is NOT using the SDK version.) Please test profusely, especially in older, especially in PPC. |
From @jhi0001-OS-X-versioning-dance.patchFrom 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
|
From @jhiCraig Berry found problems with my latest patch, here's a fixed one from him. |
From @jhiOn Fri Oct 16 07:41:35 2015, jhi wrote:
For realz. |
From @jhi0001-OS-X-versioning-dance.patchFrom 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
|
From david@justatheory.comOn Oct 14, 2015, at 3:23 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote:
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 |
From @craigberryOn Fri, Oct 16, 2015 at 8:36 AM, Jarkko Hietaniemi via RT
On the following system doing a default configuration and git clean % sw_vers |
From @jhi
My understanding from the discussion so far is that 10.6 and after it should be not be necessary at all.
|
From @craigberryOn Fri, Oct 16, 2015 at 11:18 AM, David E. Wheeler
That's kinda sorta what Jarkko's latest patch does when building on In either case (overridden from the environment or not) the Current docs define the environment setting as follows: MACOSX_DEPLOYMENT_TARGET |
From david@justatheory.comOn Oct 16, 2015, at 9:48 AM, Craig A. Berry <craig.a.berry@gmail.com> wrote:
Yeah, that sounds like a great solution.
Which is even better than what I had been assuming. Best, David |
@jhi - Status changed from 'open' to 'resolved' |
From @rjbs* Jarkko Hietaniemi via RT <perlbug-followup@perl.org> [2015-10-16T16:48:43]
Thanks for forging ahead on this. I was a bit worried because I didn't see the So, great! Thanks again. -- |
From @craigberryOn Sat, Oct 17, 2015 at 8:42 PM, Ricardo Signes
As far as I can tell, the things about POSIX conformance and so on Then we turned around and told the linker to target 10.3 no matter So the new implementation applies a consistent target version to both |
From @xdgPinging BinGOs or other motivated parties -- this also ought to go into ---------- Forwarded message ---------- I now went ahead and pushed the change as 53d1d41. via perlbug: queue: perl5 status: open -- |
From @jhiOn Saturday-201510-17 21:42, Ricardo Signes via RT wrote:
Kudos on the -mmacosx-version-min belongs to Craig Berry, I was |
From @rjbs* Jarkko Hietaniemi <jhi@iki.fi> [2015-10-19T22:09:48]
Thanks Craig! -- |
From @craigberryOn Mon, Oct 19, 2015 at 9:09 PM, Jarkko Hietaniemi <jhi@iki.fi> wrote:
There are enough kudos to go around. I think Leon T. had mentioned |
From mojca.miklavec.lists@gmail.comDne Pet 16 Okt 2015 13:48:42 je jhi napisal:
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-archive.perl.org/perl5/Ticket/Display.html?id=128980). |
Migrated from rt.perl.org#126360 (status was 'resolved')
Searchable as RT126360$
The text was updated successfully, but these errors were encountered: