Skip to content
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

Closed
p5pRT opened this issue Oct 14, 2015 · 35 comments
Closed

MACOSX_DEPLOYMENT_TARGET #14984

p5pRT opened this issue Oct 14, 2015 · 35 comments

Comments

@p5pRT
Copy link

p5pRT commented Oct 14, 2015

Migrated from rt.perl.org#126360 (status was 'resolved')

Searchable as RT126360$

@p5pRT
Copy link
Author

p5pRT commented Oct 14, 2015

From @jhi

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-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.

@p5pRT
Copy link
Author

p5pRT commented Oct 14, 2015

From @jkeenan

On Wed Oct 14 13​:45​:01 2015, jhi wrote​:

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-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.

Jarkko​:

How would this patch​:

https://rt-archive.perl.org/perl5/Ticket/Attachment/1332434/711615/0002-very-first-step-to-tidy-up-mess-around-sdk-to-use.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.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Oct 14, 2015

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Oct 14, 2015

From @craigberry

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-archive.perl.org/perl5/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-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.

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.

@p5pRT
Copy link
Author

p5pRT commented Oct 14, 2015

From @jhi

Jarkko​:

How would this patch​:

https://rt-archive.perl.org/perl5/Ticket/Attachment/1332434/711615/0002-very-first-
step-to-tidy-up-mess-around-sdk-to-use.patch

... which is from https://rt-archive.perl.org/perl5/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.

@p5pRT
Copy link
Author

p5pRT commented Oct 14, 2015

From @jhi

On Wed Oct 14 15​:24​:24 2015, jhi wrote​:

Jarkko​:

How would this patch​:

https://rt-archive.perl.org/perl5/Ticket/Attachment/1332434/711615/0002-very-first-
step-to-tidy-up-mess-around-sdk-to-use.patch

... which is from https://rt-archive.perl.org/perl5/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?

@p5pRT
Copy link
Author

p5pRT commented Oct 14, 2015

From @jkeenan

On Wed Oct 14 15​:38​:59 2015, jhi wrote​:

On Wed Oct 14 15​:24​:24 2015, jhi wrote​:

Jarkko​:

How would this patch​:

https://rt-archive.perl.org/perl5/Ticket/Attachment/1332434/711615/0002-very-
first-
step-to-tidy-up-mess-around-sdk-to-use.patch

... which is from https://rt-archive.perl.org/perl5/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.

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)

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @craigberry

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-archive.perl.org/perl5/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.

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @craigberry

On Wed, Oct 14, 2015 at 9​:53 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

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.

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

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @jhi

On Wed Oct 14 19​:53​:57 2015, craig.a.berry@​gmail.com wrote​:

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-archive.perl.org/perl5/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.

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @craigberry

On Thu, Oct 15, 2015 at 5​:57 AM, Jarkko Hietaniemi via RT
<perlbug-followup@​perl.org> wrote​:

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.

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.

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @sevan

On 14/10/2015 23​:38, Jarkko Hietaniemi via RT wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @sevan

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';

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @jhi

On Thu Oct 15 09​:56​:46 2015, venture37@​geeklan.co.uk wrote​:

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.

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.

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @jhi

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

@p5pRT
Copy link
Author

p5pRT commented Oct 15, 2015

From @sevan

Hi,

On 15/10/2015 18​:19, Jarkko Hietaniemi via RT 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.

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

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.

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

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @jhi

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.

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @jhi

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

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @jhi

Craig Berry found problems with my latest patch, here's a fixed one from him.

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @jhi

On Fri Oct 16 07​:41​:35 2015, jhi wrote​:

Craig Berry found problems with my latest patch, here's a fixed one
from him.

For realz.

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @jhi

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

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From david@justatheory.com

On Oct 14, 2015, at 3​:23 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @craigberry

On Fri, Oct 16, 2015 at 8​:36 AM, Jarkko Hietaniemi via RT
<perlbug-followup@​perl.org> wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @jhi

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.

There’s also some discussion in this issue in RT #123985.

https://rt.perl.org/Public/Bug/Display.html?id=123985#

David

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @craigberry

On Fri, Oct 16, 2015 at 11​:18 AM, David E. Wheeler
<david@​justatheory.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?

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.

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From david@justatheory.com

On Oct 16, 2015, at 9​:48 AM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

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.

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

@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

From @jhi

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

@p5pRT p5pRT closed this as completed Oct 16, 2015
@p5pRT
Copy link
Author

p5pRT commented Oct 16, 2015

@jhi - Status changed from 'open' to 'resolved'

@p5pRT
Copy link
Author

p5pRT commented Oct 18, 2015

From @rjbs

* Jarkko Hietaniemi via RT <perlbug-followup@​perl.org> [2015-10-16T16​:48​:43]

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

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

@p5pRT
Copy link
Author

p5pRT commented Oct 18, 2015

From @craigberry

On Sat, Oct 17, 2015 at 8​:42 PM, Ricardo Signes
<perl.p5p@​rjbs.manxome.org> wrote​:

* Jarkko Hietaniemi via RT <perlbug-followup@​perl.org> [2015-10-16T16​:48​:43]

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

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.

@p5pRT
Copy link
Author

p5pRT commented Oct 18, 2015

From @xdg

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 53d1d41.


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

--
David Golden <xdg@​xdg.me> Twitter/IRC/Github​: @​xdg

@p5pRT
Copy link
Author

p5pRT commented Oct 20, 2015

From @jhi

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 53d1d41.

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.

@p5pRT
Copy link
Author

p5pRT commented Oct 20, 2015

From @rjbs

* Jarkko Hietaniemi <jhi@​iki.fi> [2015-10-19T22​:09​:48]

Kudos on the -mmacosx-version-min belongs to Craig Berry, I was
merely trying to address the MACOSX_DEPLOYMENT_TARGET silliness.

Thanks Craig!

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented Oct 20, 2015

From @craigberry

On Mon, Oct 19, 2015 at 9​:09 PM, Jarkko Hietaniemi <jhi@​iki.fi> wrote​:

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 53d1d41.

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.

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2016

From mojca.miklavec.lists@gmail.com

Dne Pet 16 Okt 2015 13​:48​:42 je jhi napisal​:

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

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant