Re: gnulib fails for build on Mac OS X 10.4: get_ppid_of.c:36:22: error: libproc.h: No such file or directory

[Ryan Schmidt]

On Dec 6, 2021, at 22:55, Bruno Haible wrote:
> 
> Hi Ryan,
> 
> Ryan Schmidt wrote:
>> Hi, gnulib fails to build on Mac OS X 10.4 Tiger:
>> 
>> get_ppid_of.c:36:22: error: libproc.h: No such file or directory
>> 
>> libproc.h was introduced in Mac OS X 10.5 Leopard.
> 
> The Gnulib module 'sigsegv' is another module which supports Mac OS X 10.5
> nicely but not Mac OS X 10.4.
> 
> More generally, how do you — in MacPorts — handle the case of a functionality
> that is available in Mac OS X versions >= V, but not in versions < V? (I'm
> asking you because normal macOS users typically build binaries just for their
> particular OS version.)
> 
> Do you have a mechanism for building separate binaries for ≥ V and < V?
> 
> Do you attempt to build the code for ≥ V, even though it won't work for < V?
> 
> Do you use a replacement for the versions < V, and a version test at runtime
> (and, if so, how do you code this version test)?
> 
> Do you have a timeline when you will drop support for Mac OS X 10.4?

Hi Bruce,

The MacPorts base system (i.e. the `port' command) requires Mac OS X 10.4 or 
later. MacPorts base doesn't use a lot of Mac-specific functionality so nothing 
has come up yet that would require us to drop support for that version. The 
thousands of individual ports that can be installed with MacPorts each have 
different requirements, and a large number of them surely don't build on 10.4 
anymore since it is so old, but some ports still do, and we do still have a few 
users who like using MacPorts to install software on their old PowerPC Macs, 
some of which can't officially be upgraded past 10.4 and none of which can be 
upgraded past 10.5.

macOS has a mechanism for allowing software to be built on newer OS versions 
but such that it can still be run on older OS versions: the 
MACOSX_DEPLOYMENT_TARGET environment variable or equivalently the 
-mmacosx-version-min compiler flag. The way that Apple intends this to be used 
is that a developer will use the most recent macOS and OS SDK on their 
compilation and development computer, and then specify which minimum OS version 
they require users to have. Any symbols available in the minimum desired OS 
version will be linked normally (guaranteed to be available at runtime) while 
any symbols available only in newer systems will be weak-linked; it is the 
responsibility of the application or library developer to know that this might 
happen, and to have the software check at runtime whether such symbols exist, 
and to only use the functionality at runtime if it exists.

Because many open source projects are written by developers not aware of these 
Mac-specific features, MacPorts doesn't normally rely on this. MacPorts 
normally sets the deployment target to be the same as the running OS version, 
and ports are built on the same OS version on which they will be used. We have 
separate build machines for each major OS version (in some cases two, for 
situations where the OS is available on multiple processor architectures) and 
when a user installs a port, MacPorts first tries to download a binary built 
for and on that OS version, and if that fails, then it compiles from source on 
the user's machine.

But if you are developing a portable library, you would want to support 
compiling for an earlier macOS than the one you're compiling on.

The problem with Apple's suggested approach is that while it works great for 
the developer who compiles and releases binaries, it works less well for open 
source software where users want to compile the software, if the user doesn't 
have the latest OS or OS SDK. Supposing that libproc.h declares functions you 
want to call that are available on 10.5 but not 10.4, and that this 
functionality is optional and you can code around its absence, you could modify 
gnulib so that it checks at runtime and only calls those functions if they 
exist. That would help someone who is on 10.4 using a gnulib that was built on 
10.5 using deployment target 10.4, but it doesn't help someone trying to build 
on 10.4 because 10.4 doesn't have libproc.h and the 10.5 SDK isn't available in 
any Xcode version that's compatible with 10.4.

To solve that problem, in addition to the preceding about checking for 
weak-linked symbols, you can use preprocessor defines within the source code, 
and only include libproc.h and only compile the code that uses its functions if 
your SDK is 10.5 or greater. The relevant defines are 
MAC_OS_X_VERSION_MAX_ALLOWED and MAC_OS_X_VERSION_MIN_REQUIRED. 
MAC_OS_X_VERSION_MAX_ALLOWED refers to the SDK version. For example to include 
libproc.h only if you are compiling with the 10.5 SDK or later:

#if MAC_OS_X_VERSION_MAX_ALLOWED >= 1050
#include <libproc.h>
#endif

MAC_OS_X_VERSION_MIN_REQUIRED refers to the deployment target. If you want to 
know that your code is guaranteed to be running on 10.5 or later:

#if MAC_OS_X_VERSION_MIN_REQUIRED >= 1050

You might use this, for example, to write more efficient code: If you're 
deploying for 10.5 or later, then those symbols only available in 10.5 or later 
will be normally linked, not weak linked, so you don't need to check if they 
exist; you already know they do.

For those two defines to exist, you have to include AvailabilityMacros.h, which 
you should do only on Apple platforms:

#ifdef __APPLE__
#include <AvailabilityMacros.h>
#endif

In 10.5, Apple introduced a new header Availability.h which they want you to 
use instead of AvailabilityMacros.h, but since the goal here is to support 
10.4, which doesn't have that header, you'd have to keep using 
AvailabilityMacros.h.

A MacPorts user running Mac OS X 10.4 proposed this fix which just hides the 
#include of <libproc.h> and its uses behind the 10.5 deployment target check, 
without attempting to provide any alternative when deploying for earlier 
versions nor attempting to allow libproc features to be used if running on 10.5 
or greater when compiled for 10.4. I commented that I did not know whether this 
fix was correct and asked them to bring it up on this list, but since I don't 
think they have, I'm bringing it up for them.

https://github.com/macports/macports-ports/pull/13226/files#diff-8a2ad00cea356fb07a25e323fde8a18232252de4f6421d5e73347aa845d56045

(They used __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ instead of 
MAC_OS_X_VERSION_MIN_REQUIRED; the distinction is not clear to me. It might be 
that __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ is defined even if 
AvailabilityMacros.h is not included.)

We may also need to think about what happens when compiling for a non-macOS 
Apple OS (iOS, iPadOS, tvOS, watchOS). I don't think *MAC_OS_X* defines will be 
defined on those other OSes. In MacPorts we don't try to solve the problem 
since we only compile for macOS.