latest OSX XCode is buggy and fails to build postgis

[robe]

​http://stackoverflow.com/questions/39536144/libsystem-symptoms-dylib-missing-in-xcode-8

Patch from pramsey attached

[robe]

In 15153:

PostGIS not building on latest OSX XCode
References #3643 for PostGIS 2.3.1 (patch from pramsey)

[robe]

In 15155:

PostGIS not building on latest OSX XCode
Closes #3643 for PostGIS 2.4.0 (patch from pramsey)

[robe]

reopened - we might want to take this out or replace with better patch per Greg and Paul

[gdt]

The real problem is that there is a bug in XCode, not a bug in postgis. Rewrite to give the reader the right impression.

[gdt]

I think this patch should be reverted (or replaced) before any release. It tries to run xcrun on systems not known to be OS X, and emits messages about OS X being ok or not on those other systems.

[gdt]

There's a much larger question lurking here about the degree to which various open-source programs should have workarounds for outright bugs in toolsets, especially in cases when the bugs will cause build failures for large numbers of programs. It might be better to point people at how to fix their build environments instead. But I can see that it might be more useful to have a workaround.

[robe]

FYI I'm planning on reverting this patch for 2.3.1 and 2.4.0. Speak now if you have issue.

[pramsey]

Yes, have an issue, since then OSX people will again be unable to build from source. Would a quieter patch be considered a fix?

[gdt]

I would be in favor of a README entry pointing to something out on the web that explains to people on OSX how to fix their systems and what the bug report id is that's been filed with Apple about this.

But if there is a workaround, and it 1) does not attempt to do anything on other than OS X and 2) doesn't print anything alarming (xcrun found, SDK version is 10.11 is ok) on unaffected OSX, and 3) doesn't actually change anything unless the bug is found (seems ok), then it seems ok. I think it's better to just revert it if there isn't a clean way for other systems. But, I suspect that just wrapping the entire change in a test for OS being Darwin and toning down the messages for other than 10.12 is enough.

[pramsey]

I've os-guarded the code and made it less scary in r15230, can back-port to stable easily enough

[pramsey]

I put it into 2.3 as well at r15231

[robe]

Thanks pramsey - the gods and goddesses of postgis hope for a speedy recovery of your muscle and skeletal aches :)

[gdt]

        if test "x$XCRUN" = "x"; then
                AC_MSG_RESULT([using OSX XCode... yes])
        else

Shouldn't that be "no"? (output error, not logic error in what actually happens.

[robe]

Reading that I would agree it should be a no. Probably should change even though it's a pointless message. I'm not sure we need to even show anything for that case.

Are BSDs considered Darwin based system too so does this only shows on them because they are Darwin and don't run XCode. Sorry for my ignorance.

[gdt]

I did not see this printed out. My comment is just from code review. That branch could be taken if one constructed a build with compilers other than from xcode and hid xcrun. Perhaps unusual, but if we're checking for it (and good to check assumptions one by one), the message might as well be right.

No, the BSD systems (FreeBSD, NetBSD, OpenBSD, Dragonfly, and more forks) are definitely not Darwin. Darwin refers to a system developed by Apple which is a combination of Mach and BSD code. As I understand, fairly fuzzily, there is fair bit of FreeBSD code (various), and a fair bit of NetBSD code (networking). In theory Darwin is open source, and it used to be possible to build Darwin itself and run it. OS X (now MacOS) is Darwin the base system plus the mac stuff on top. Which is a long way of saying that today, ifdef Darwin is really about MacOS only.

[pramsey]

Change message to say "no", r15237 and r15238

[robe]

I'm happy. Closing this out.