postgresql10, postgresql11: Undefined symbols _clock_gettime

[ryandesign (Ryan Carsten Schmidt)]

postgresql10 fails to build on OS X 10.11 and earlier:

Undefined symbols for architecture x86_64:
  "_clock_gettime", referenced from:
      _ExplainOneQuery in explain.o
      _ExplainOnePlan in explain.o
      _elapsed_time in explain.o
      _ExplainExecuteQuery in prepare.o
      _lazy_vacuum_rel in vacuumlazy.o
      _InstrStartNode in instrument.o
      _InstrStopNode in instrument.o
      ...
ld: symbol(s) not found for architecture x86_64

clock_gettime was new in macOS 10.12.

Upstream should add compatibility code for earlier systems.

Until they do, you can include the legacysupport 1.0 portgroup, which will add our compatibility implementation.

I did not check if other postgresql ports need this too. I would guess that some others do too.

[ryandesign (Ryan Carsten Schmidt)]

I was wrong: this problem only affects 10.11. Postgresql appears to already have a way of dealing with the lack of clock_gettime, but even though it was introduced in 10.12, it thinks it is available on 10.11.

The reason for this is that the configure script uses the latest SDK, even though we did not tell it to do that. The latest Xcode on 10.11 includes the 10.12 SDK. The configure script gets the path of the latest SDK from xcodebuild and adds it to CPPFLAGS in the form of an -isysroot flag, which explains why the configure script detects that clock_gettime is available. But it neglects to also add the SDK path to LDFLAGS in the form of a -syslibroot flag, which is why it fails at link time.

Trying to add the legacysupport portgroup fails because of conflicting definitions of clock_gettime between the legacy support headers and the 10.12 SDK's definition. But since postgresql already knows how to deal with the lack of clock_gettime, we should not add this portgroup.

Probably the best solution is explain to postgresql that it should not attempt to make its own decisions about which SDK to use, which I will commit in a moment. MacPorts already adds -isysroot and -syslibroot flags when required.

[ryandesign (Ryan Carsten Schmidt)]

In ee193a0d097dd90d2423c1b93a934d7c1041620e/macports-ports (master):

postgresql*: Don't override MacPorts SDK choice

Closes: #57588

[kencu (Ken)]

don't forget we have discovered syslibroot does absolutely nothing useful, with clang toolchains on masOS, at least.

It's all isysroot, even for linking.

[ryandesign (Ryan Carsten Schmidt)]

I know you're discussing that issue elsewhere. It's not relevant to this ticket. The fact is Postgresql was trying to second-guess MacPorts' SDK choice, and I've fixed it by preventing it from doing that.