Odd Behavior in macOS Mojave

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Odd Behavior in macOS Mojave

Steven Stallion
All,

It appears there have been some changes to how macOS handles the
system include path starting with macOS Mojave. It looks like Apple
has provided a workaround package you can install to re-instate the
/usr/include hierarchy, however I was wondering if this is something
that could be handled by AppleClang support?

Has anyone else encountered this yet?

Cheers,
Steve
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Odd Behavior in macOS Mojave

Sean McBride
On Tue, 13 Nov 2018 18:42:43 -0600, Steven Stallion said:

>It appears there have been some changes to how macOS handles the
>system include path starting with macOS Mojave. It looks like Apple
>has provided a workaround package you can install to re-instate the
>/usr/include hierarchy, however I was wondering if this is something
>that could be handled by AppleClang support?

Could you elaborate?  What odd behaviour are you seeing?  Any error message to share?  What 'workaround package' are you speaking of?  What version of Xcode?

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Odd Behavior in macOS Mojave

Steven Stallion
On Wed, Nov 14, 2018 at 8:19 AM Sean McBride <[hidden email]> wrote:

> Could you elaborate?  What odd behaviour are you seeing?  Any error message to share?  What 'workaround package' are you speaking of?  What version of Xcode?

We first noticed that some sources would fail to find certain system
headers (stddef.h in this case) when using Xcode 10 (also seen on
Xcode 10.1). It looks like Apple decided to relocate system include
paths under /Library /Developer and did away with /usr/include. After
some spelunking, it looks like this was tucked away in the release
notes for Xcode:
https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes

"The Command Line Tools package installs the macOS system headers
inside the macOS SDK. Software that compiles with the installed tools
will search for headers within the macOS SDK provided by either Xcode
at:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

or the Command Line Tools at:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

depending on which is selected using xcode-select.

The command line tools will search the SDK for system headers by
default. However, some software may fail to build correctly against
the SDK and require macOS headers to be installed in the base system
under /usr/include. If you are the maintainer of such software, we
encourage you to update your project to work with the SDK or file a
bug report for issues that are preventing you from doing so. As a
workaround, an extra package is provided which will install the
headers to the base system. In a future release, this package will no
longer be provided. You can find this package at:

/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg


To make sure that you're using the intended version of the command
line tools, run xcode-select -s <path to Xcode> or xcode select -s
/Library/Developer/CommandLineTools after installing."

Installing the package seemed to resolve the issues we had building
with AppleClang, which made me wonder if something is needed in the
platform modules to account for this change.

HTH,
Steve
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Odd Behavior in macOS Mojave

Sean McBride
On Wed, 14 Nov 2018 10:43:28 -0600, Steven Stallion said:

>We first noticed that some sources would fail to find certain system
>headers (stddef.h in this case) when using Xcode 10 (also seen on
>Xcode 10.1). It looks like Apple decided to relocate system include
>paths under /Library /Developer and did away with /usr/include. After
>some spelunking, it looks like this was tucked away in the release
>notes for Xcode:
>https://developer.apple.com/documentation/xcode_release_notes/
>xcode_10_release_notes

I see.  Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot "RogueResearch12" and indeed it does not have a /usr/include folder.  It is however able to build CMake, VTK, and ITK nightly without any compiler errors.

Perhaps it's not so much a CMake bug as a bug in the project you're trying to build?

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Odd Behavior in macOS Mojave

Steven Stallion
On Wed, Nov 14, 2018 at 10:54 AM Sean McBride <[hidden email]> wrote:

> I see.  Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot "RogueResearch12" and indeed it does not have a /usr/include folder.  It is however able to build CMake, VTK, and ITK nightly without any compiler errors.
>
> Perhaps it's not so much a CMake bug as a bug in the project you're trying to build?

Interesting. I'll take another look - I wonder if it's a bad
interaction from calling clang from a custom command.

Thanks for taking a look!
Steve
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Odd Behavior in macOS Mojave

Bo Zhou
At MacOS, in 99% cases, the build task always needs to setup the variables
  • CMAKE_OSX_TARGET
  • CMAKE_OSX_DEPLOYMENT_TARGET
This 2 variables are important. The CMAKE_OSX_TARGET would define the minimal set of API during compilation, and this affects the built binary. The second is the path to the OSX SDK, usually it stays in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs . Since SDK changes file and directory structure according the language feature, this is important to the program which has to use C++11 or C++14 or new header files.

Personally I only use 10.9 SDK, which is the first version migrated to C++11, and SDK changed a lot compared to 10.8, and the program is compatible with the later system.

On Thu, Nov 15, 2018 at 3:42 AM Steven Stallion <[hidden email]> wrote:
On Wed, Nov 14, 2018 at 10:54 AM Sean McBride <[hidden email]> wrote:

> I see.  Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot "RogueResearch12" and indeed it does not have a /usr/include folder.  It is however able to build CMake, VTK, and ITK nightly without any compiler errors.
>
> Perhaps it's not so much a CMake bug as a bug in the project you're trying to build?

Interesting. I'll take another look - I wonder if it's a bad
interaction from calling clang from a custom command.

Thanks for taking a look!
Steve
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake