Fix Broken MacOS Build

[tomchappell]

The existing LDSFLAGS is not working -- the $(xcode-select -p) within it is evaluating as "" -- it doesn't even seem to be executed. bmake problem?

Fixed by using the != execute-and-assign operator, and also by adding -lSystem parameter.

[sfstewman]

Hi @tomchappell!

Thank you for the PR! @katef asked me to test this, as I'm one of the few libfsm devs that actually uses macOS for development work. Testing on my MBP 2013, which runs Big Sur (macOS 11.6.4), I think the path relative to ${XCODE_SELECT_P} needs a small modification.

The PR should be compatible with at least Big Sur if you change the LDSFLAGS entry in so.mk to:

LDSFLAGS ?= -dylib -flat_namespace -undefined dynamic_lookup -L${XCODE_SELECT_P}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib -lSystem

This should also work on Monterey, although I can't test that until at least this weekend.

[tomchappell]

The PR should be compatible with at least Big Sur if you change the LDSFLAGS entry in so.mk to:

LDSFLAGS ?= -dylib -flat_namespace -undefined dynamic_lookup -L${XCODE_SELECT_P}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib -lSystem

Thanks, will check it out!

[tomchappell]

Hey sfstewman, the suggested change does NOT work on Monterey (I have 12.2.1), where we find the following:

sh-3.2$ xcode-select -p
/Library/Developer/CommandLineTools

sh-3.2$ ls /Library/Developer/CommandLineTools
Library	SDKs	usr

sh-3.2$ find !$ -name Platforms
find /Library/Developer/CommandLineTools -name Platforms

sh-3.2$ 

...so we see that there exists no directory named Platforms anywhere under the path returned by xcode-select -p,

[tomchappell]

...but the PR as it is does work on (my) Monterey 12.2.1.

[sfstewman]

Hey @tomchappell! That's frustrating. I think I know what's going on. I'll have a chance to check it out this weekend.

I think the issue is whether the XCode command-line tools are installed or not. If they're not installed, xcode-select -p seems to return /Library/Developer/CommandLineTools, and if they are, it returns /Applications/XCode.app/Contents/Developer.

Unfortunately, while /Applications/XCode.app/Contents/Developer/usr/lib exists, it doesn't have libSystem.dylib in it.

One solution is to test for the existence of $(xcode-select -p)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib and fall back to $(xcode-select -p)/usr/lib if it doesn't exist. This would solve the problem, but it may make it hard to ship a macOS program (eg: MyThing.app that uses libfsm for something cool) to a user that doesn't have the XCode command-line tools installed.

I'm sure there's a better solution. I'm not a hardcore macOS developer; I mostly work on Linux these days.

[katef]

Worth mentioning I think we can xcode-select --install in the github CI at least. This won't help for the situation @sfstewman is describing with people downloading and building the software, but it might resolve the problem where xcode-select -p produces no output for github's machines.

edit: apparently not... xcode-select --install gives:

xcode-select: error: command line tools are already installed, use "Software Update" to install updates

[tomchappell]

Yeah, on my Monterey box, the XCode command-line tools ARE installed, and it returns the (correct and usable) /Library/Developer/CommandLineTools path, and libfsm builds correctly (with the changes in this PR).

% xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

% xcode-select -p 
/Library/Developer/CommandLineTools

% 

[sfstewman]

So, I did check this on a Monterey box before I posted my thoughts on xcode-select -p. And the returns did change between before installing the command-line tools and after. It's not a box that I can do libfsm development on, so I can't test the full build, or really dig into what's going on. I do have an iMac that I can test the build on, but it needs some work before it's usable for dev stuff, and I'm not sure I can get to that for another week or so.

We could merge and sort it out later. @katef ?

[joeshaw]

See also #10. I just ran into this. Rebasing this branch against main fixes the libfsm build for me on arm64 macOS Sequoia 15.7.2.