make fails under MacOS

[dmopalmer]

This may be a cFS issue (initial step is to check out cFS and work from its directory, but then cfe/Makefile is copied and used). The issue may be moved to the appropriate repo.

When following the instructions in the README on a Mac (either Intel or Apple Silicon ARM) , the first make fails with

CMake Error at cmake/arch_build.cmake:542 (message):
  Do not know how to set CFE_SYSTEM_PSPNAME on Darwin system
Call Stack (most recent call first):
  CMakeLists.txt:120 (prepare)

This looks like a regression or maybe an untested case of #629 .

Steps to reproduce the behavior:

On a Mac, follow the instructions in the README to clone the project and then start the first make:

git clone https://github.com/nasa/cFS.git
cd cFS
git submodule init
git submodule update
cp cfe/cmake/Makefile.sample Makefile
cp -r cfe/cmake/sample_defs sample_defs

so far so good

 make SIMULATION=native prep

fails with first error message to console:

CMake Error at cmake/arch_build.cmake:542 (message):
  Do not know how to set CFE_SYSTEM_PSPNAME on Darwin system
Call Stack (most recent call first):
  CMakeLists.txt:120 (prepare)

The CMakeError.log file says:

ld: library not found for -lSystem

but that may be a secondary cascade error.

I would expect it to compile without error.

This is observed on both a MacBook M1 and a Mac Pro (Intel), both with latest macOS (11.5.2) and toolchain (Xcode 11.5.1; cmake 3.20.5; AppleClang 12.0.5.12050022). zsh shell (but same result under bash).

Output of make attached:
make_output.txt
CMakeError.log
CMakeOutput.log

[jbohren-hbr]

You should be able to get past the missing library by including an explicit link directory in your LDFLAGS assuming this path exists and has libSystem.dylib:

export LDFLAGS=-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib

Not finding libSystem on macOS is a pretty common issue with 11.x, since it was moved out of /usr/lib:

New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286) [ref]

For the last few years now, Mac OS has traded developer-friendliness for security, so it generally requires a little more direction than development on Linux.

[dmopalmer]

It doesn't work, failing with the same errors.

Does it matter that the files in
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib are library stub .tbd files such as libSystem.tbd instead of .dyld files?

[skliper]

Although there are some community member contributions related to building cFS for a MacOS target (see nasa/osal#1161, nasa/osal#1140), it isn't an officially supported target ( which basically means we don't have a stakeholder providing resources to support it). If you requirements allow it, it may be easier to utilize a Linux docker/VM or QEMU target that is supported and provides a shorter path to a more typical production target.

[skliper]

Although this issue relates to something not working (ie, "bug"), it's related to an unsupported build env (MacOS). Labeling as "enhancement" to consider supporting MacOS.