Re: BUG #15190: Build configure should have option to disable clock_gettime on MacOS 10.12 and up.

=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)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