Thread: BUG #15190: Build configure should have option to disableclock_gettime on MacOS 10.12 and up.

The following bug has been logged on the website:

Bug reference:      15190
Logged by:          Marc Van Olmen
Email address:      marcvanolmen@gmail.com
PostgreSQL version: 10.3
Operating system:   MacOS 10.13
Description:

Steps to reproduce issue.

1. Use MacOS 10.12 or higher. I tested MacOS 10.13 because for latest Xcode
9.3 this is the minimal system.
2. Run the standard configure command and make and make install.
3. It will produce an executable for example ./lib/postgress that use the
function clock_gettime.
4. Trying to run this produced executable on macOS 10.10 or lower will
produce the following error

dyld: Symbol not found: _clock_gettime
  Referenced from:
/Volumes/Checkout/Checkout.app/Contents/Resources/postgres_10/bin/postgres
  Expected in: /usr/lib/libSystem.B.dylib

Proposed solution:

We should have an option that disable to the automatic search for using the
clock_gettime on MacOS 10.12 or higher


Other open source projects have also introduced similar options:

./configure --disable-clock-gettime  

https://github.com/libevent/libevent/issues/399
https://github.com/libevent/libevent/pull/400/files

thanks,

Marc Van Olmen

=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> 1. Use MacOS 10.12 or higher. I tested MacOS 10.13 because for latest Xcode
> 9.3 this is the minimal system.
> 2. Run the standard configure command and make and make install.
> 3. It will produce an executable for example ./lib/postgress that use the
> function clock_gettime.
> 4. Trying to run this produced executable on macOS 10.10 or lower will
> produce the following error
> dyld: Symbol not found: _clock_gettime

This does not seem like a bug, but user error; or at least, you're
thinking about the problem in the wrong way.  In general, an executable
built on version N of an operating system is not guaranteed to run on
versions before N, because of missing features.  clock_gettime is just one
example of such a feature.  We surely aren't going to introduce configure
options to override every test it makes; but that would be the logical
end result if we proceed as you suggest.  That would be unmaintainable,
and not very usable either --- how would you know which things have to
be disabled to get an executable that works on a desired old OS version?

The right way to proceed is to build in an environment that mimics your
oldest target OS version.  Apple does provide facilities for doing that.
I haven't done it, but IIUC the idea is to install the SDK version
corresponding to your target OS version and then point at that while
building.  See


https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html

particularly this bit:

    Configuring a Makefile-Based Project

    If you have a makefile-based project, you can also take advantage of
    SDK-based development, by adding the appropriate options to your
    compile and link commands. Using SDKs in makefile-based projects
    requires GCC 4.0 or later. To choose an SDK, you use the -isysroot
    option with the compiler and the -syslibroot option with the
    linker. Both options require that you specify the full path to the
    desired SDK directory.

Now, if you've tried that and it doesn't work, we could look into
why not.  But I don't think that expecting executables built in a
default environment to be back-portable is going to get anywhere.

            regards, tom lane