Build problems with macOS Sonoma

[lpar]

In file included from /Users/meta/Programming/Go/src/github.com/RJVB/afsctool/src/utils.cpp:10:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/string:537:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/__algorithm/max.h:13:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/__algorithm/comp_ref_type.h:13:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/__debug:16:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/cstddef:46:5: error: <cstddef> tried including <stddef.h> but didn't find libc++'s <stddef.h> header.           This usually means that your header search paths are not configured properly.           The header search paths should contain the C++ Standard Library headers before           any C Standard Library, and you are probably using compiler flags that make that           not be the case.
#   error <cstddef> tried including <stddef.h> but didn't find libc++'s <stddef.h> header. \
    ^

It looks as if stddef.h is in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stddef.h
rather than
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/stddef.h

i.e. Apple seem to have split the C++ headers into two locations, or stopped supporting C++ in the 14.0 SDK.

There's also a /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk/usr/include/ which seems to include both string and stddef.h, and the name suggests it may be appropriate. Unfortunately I don't know enough about Cmake to know how to try it.

[RJVB]

On Wednesday September 27 2023 10:17:25 mathew wrote: ``` /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/c++/v1/cstddef:46:5: error: <cstddef> tried including <stddef.h> but didn't find libc++'s <stddef.h> header. This usually means that your header search paths are not configured properly. The header search paths should contain the C++ Standard Library headers before any C Standard Library, and you are probably using compiler flags that make that not be the case. # error <cstddef> tried including <stddef.h> but didn't find libc++'s <stddef.h> header. \ ```

This rings a bell, now if I could remember where the clapper is ... :)

[nichtverstehen]

This line in CMakeLists.txt adds MacOS SDK dir to the CXX_INCLUDES in the wrong position:

include_directories(${ZLIBP_INCLUDE_DIR})

Not sure what the right solution is, but removing it unblocks compilation.

[RJVB]

``` include_directories(${ZLIBP_INCLUDE_DIR}) ``` Not sure what the right solution is, but removing it unblocks compilation.

Where is your zlib installed and what is `ZLIBP_INCLUDE_DIR` set to?

[nichtverstehen]

> pkg-config --variable=includedir zlib
/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include
> pkg-config --cflags zlib

> pkg-config --debug zlib
...
Reading 'zlib' from file '/opt/homebrew/Library/Homebrew/os/mac/pkgconfig/13/zlib.pc'

Perhaps FindZLIBP.cmake should respect cflags or cflags-only-I (empty in this case) instead of trying to extract includedir variable.

[RJVB]

> pkg-config --variable=includedir zlib /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include > pkg-config --cflags zlib

Let me guess, your /usr/include is a symlink to a directory under the SDK dir?

Perhaps FindZLIBP.cmake should respect `cflags` or `cflags-only-I` instead of trying to extract `includedir` variable.

The nuisance is that I cannot pass that output to CMake's `include_directories` (AFAIK). So what we're talking about here is a superfluous `-I/usr/include` . It stymies me that that can wreak havoc.

[nichtverstehen]

> ls -ld /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include
drwxr-xr-x  302 root  wheel  9664 Jul  4 18:08 /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include/
> ls -ld /usr/include
ls: /usr/include: No such file or directory

Generally, my machine is a pretty vanilla Sonoma install + Xcode CLT + Xcode 16 + a few Homebrew packages. I didn't create any special symlinks.

The offending arg is -I/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include. It comes from includedir variable of zlib.pc. Here's what my zlib.pc is:

> cat /opt/homebrew/Library/Homebrew/os/mac/pkgconfig/13/zlib.pc
homebrew_sdkroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
prefix=${homebrew_sdkroot}/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib
sharedlibdir=${libdir}
includedir=${prefix}/include

Name: zlib
Description: zlib compression library
Version: 1.2.11

Requires:
Libs: -L${libdir} -L${sharedlibdir} -lz
Cflags:

TBH, I don't know why Homebrew is providing pkgconfig for the system install of zlib.

In any case, most important thing is that the build works for you as the maintainer and there is a workaround for this issue that affects some users.

[RJVB]

On Wednesday October 23 2024 02:02:34 Kirill Nikolaev wrote: The offending arg is `-I/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include`. It comes from `includedir` variable of `zlib.pc`. Here's what my zlib.pc is:

My point was that this shouldn't be offending in any way.

TBH, I don't know why Homebrew is providing pkgconfig for the system install of zlib.

Oh, whew. For a second you had me wondering why they'd violate just about every principle and install stuff in a system directory! Don't they provide a non-shim zlib package that installs a newer version (or a compatibility build of zlib-ng that will give improved performance)?

In any case, most important thing is that the build works for you as the maintainer and there is a workaround for this issue that affects some users.

Give me a replacement implementation of my .cmake file that obtains the directory name from `pkg-config --cflags-I` and I'll test and integrate it on my systems ;)