PlatformIO Community

[Solved] Xtensa-esp32-elf-g++ error -mmacosx-version-min

A few version numbers to help put the issue in context -

  • macOS 10.14
  • CLion 2019.2.2
  • PlatformIO 4.0.3
    • espressif32 1.10.0
    • toolchain-xtensa32 2.50200.80

I’ve used PIO + CLion successfully before, and it’s an amazing combination of tools. For whatever reason, I went to use it tonight and when I create my first empty .cpp file in a new PIO project, I get an error in the CMake output frame:

-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rhornsby/projects/esp32/tmp/cmake-build-nodemcu-32s

Problems were encountered while collecting compiler information:
	xtensa-esp32-elf-g++: error: unrecognized command line option '-mmacosx-version-min=10.14'

The specific platform (nodemcu, esp32thing) doesn’t seem to matter.

I tried removing the ‘espressif32’ platform and re-installing it, to no avail. Cross compilers and such are way outside my area of expertise, but the binary xtensa-esp32-elf-g++ --help says that -m options will be passed to subprocesses:

Options starting with -g, -f, -m, -O, -W, or --param are automatically
 passed on to the various sub-processes invoked by xtensa-esp32-elf-g++.

There’s also a --target-help which lists some -m options, but none of them are macos-version-min

I have a sneaking suspicion that maybe somehow Xcode is a culprit here, only because it usually is, but I don’t know where to look.

Any ideas, or information I can provide to help troubleshoot? thanks!

Edit: I went hunting for strings in the cmake-build-<platform> directory and came across this. I don’t know if it matters, it stood out to me since I’m on 10.14 not 10.15, but the Xcode(!) path being referenced is 10.15.

CMakeFiles/tmp.dir/link.txt:/Users/rhornsby/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -mmacosx-version-min=10.14 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/tmp.dir/src/test.cpp.o -o tmp

Remembered this morning I have a MacBook which it turns out I hadn’t run the App Store update yet to get the newer Xcode - the SDK version (directory name, that is) is still “10.14”.

Frustratingly[1], that “fixed” the problem, as it were. All other things - steps to recreate the problem, versions etc - being equal to the best of my knowledge, Xcode is …at fault? The source of the issue?

I’m not running any betas, developer versions, etc. The Xcode update is what’s available on the App Store right now. My MacBook wants to update, I just hadn’t bothered yet. It seems likely updating will break the toolchain?

[1] Have a mental image of Sheldon Cooper shaking his fist in the air but instead of “Wheeeaton!” it’s me yelling “XCooooode!”

1 Like

Fixed it by removing/uninstalling the App Store version of Xcode, and installing the older version (10.3) from https://developer.apple.com/download/more/

It won’t get updates from the App Store anymore this way, but for me that doesn’t matter.