Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#57588 closed defect (fixed)

postgresql10, postgresql11: Undefined symbols _clock_gettime

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: jyrkiwahlstedt
Priority: Normal Milestone:
Component: ports Version:
Keywords: elcapitan Cc:
Port: postgresql10, postgresql11

Description

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.

Change History (4)

comment:1 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: elcapitan added
Port: postgresql11 added
Summary: postgresql10: Undefined symbols _clock_gettimepostgresql10, postgresql11: Undefined symbols _clock_gettime

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.

comment:2 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

In ee193a0d097dd90d2423c1b93a934d7c1041620e/macports-ports (master):

postgresql*: Don't override MacPorts SDK choice

Closes: #57588

comment:3 Changed 6 years ago by 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.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:4 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.