Opened 8 years ago

Closed 8 years ago

#3643 closed patch (fixed)

latest OSX XCode is buggy and fails to build postgis

Reported by: robe Owned by: pramsey
Priority: medium Milestone: PostGIS 2.3.1
Component: postgis Version: 2.2.x
Keywords: Cc:


Attachments (1)

osx-1012.patch (732 bytes ) - added by robe 8 years ago.

Download all attachments as: .zip

Change History (20)

by robe, 8 years ago

Attachment: osx-1012.patch added

comment:1 by robe, 8 years ago

Type: defectpatch

comment:2 by robe, 8 years ago

In 15153:

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

comment:3 by robe, 8 years ago

Resolution: fixed
Status: newclosed

In 15155:

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

comment:4 by robe, 8 years ago

Resolution: fixed
Status: closedreopened

comment:5 by robe, 8 years ago

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

comment:6 by gdt, 8 years ago

Summary: PostGIS not building on latest OSX XCodelatest OSX XCode is buggy and fails to build postgis

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

comment:7 by gdt, 8 years ago

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.

comment:8 by gdt, 8 years ago

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.

comment:9 by robe, 8 years ago

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

comment:10 by pramsey, 8 years ago

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

comment:11 by gdt, 8 years ago

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.

comment:12 by pramsey, 8 years ago

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

comment:13 by pramsey, 8 years ago

I put it into 2.3 as well at r15231

comment:14 by robe, 8 years ago

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

comment:15 by gdt, 8 years ago

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

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

comment:16 by robe, 8 years ago

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.

comment:17 by gdt, 8 years ago

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.

comment:18 by pramsey, 8 years ago

Change message to say "no", r15237 and r15238

comment:19 by robe, 8 years ago

Resolution: fixed
Status: reopenedclosed

I'm happy. Closing this out.

Note: See TracTickets for help on using tickets.