Intel® C++ Compiler
Support and discussions for creating C++ code that runs on platforms based on Intel® processors.
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
7662 Discussions

How to use the Intel Classic C++ Compiler with macOS 11 (Big Sur)



This is not a question, but a solution.  

If one looks in the release notes for the latest oneAPI C++ Compiler, you will come across a disheartening message if your system is running macOS Big Sur:


macOS Big Sur 11 Not Supported

Errors will be missing libraries such as -lSystem not found


The release notes then proceed to blame this on the lack of .dylib files in the Big Sur filesystem, but this is incorrect.  


All the normal and expected libraries are still located in exactly the same locations with exactly the same names, only now they are text stubs with the file extension .tbd instead of .dylib.  


This change is totally transparent as the system linker knows what to do.  Which is why this change did not break clang or gcc, or any other compiler that intends to link to libraries on macOS.  The macOS release notes that Intel's own release notes derive this from was very specifically talking about code or programs that explicitly hard coded lookups for .dylib files on the filesystem.  This is not relevant to a compiler which instead relies on the linker to figure this out.  Do you say -lc++ or -llibc++.1.dylib?  If intel's C++ compiler was actually looking directly at the filesystem, then it would break all compatibility with things like gcc as linking libraries by name and not by filename would not work.


The real reason Big Sur isn't supported (but should be) is because there is a bug somewhere in Intel's compiler that is causing it to incorrectly fill in the linker arguments -syslibroot and further omits -isysroot entirely, both of which are needed for ld to find anything.  


Note: line breaks were added for readability, but are not present in the actual ouput


$ icc -v test.c


-dynamic -arch x86_64 -weak_reference_mismatches non-weak -macosx_version_min 10.16
-syslibroot "2021-07-02 06:12:18.288 xcodebuild[89156:2413869] [MT] DVTSDK:
 Skipped SDK /Applications/"


ld: library not found for -lc++




Well of course it wasn't found, icc was passing this as the root of the macOS Library path: '2021-07-02 06:12:18.288 xcodebuild[89156:2413869] [MT] DVTSDK: Skipped SDK /Applications/"


This is trivial to fix, simply pass the correct arguments to begin with so the implicit default (which is incorrect) isn't used, and likewise provide the missing one:




$ icc -syslibroot `xcrun --show-sdk-path`  -isysroot `xcrun --show-sdk-path` test.c

Success! ^_^




The fix is the same for icpc.  It works when building a large cmake project (I tried building xmrig, an open source RandomX CPU miner, it seemed appropriate) that links not just to standard libraries but core macOS frameworks like IOKit.  


For cmake, it is as simple as adding:




CFLAGS="-syslibroot `xcrun --show-sdk-path`  -isysroot `xcrun --show-sdk-path`" CXXFLAGS="-syslibroot `xcrun --show-sdk-path` -isysroot `xcrun --show-sdk-path`" cmake <....>




to your environment variables when you run it for the first time. 

And it worked without issue.  Intel's C++ compiler finds everything without issue, from libraries to frameworks, links it just like one would expect without any special hacks or anything else required.  It just works - and there is no reason it wouldn't.  Like I said, the removal of files with the .dylib suffix shouldn't impact anything as far as the compiler is concerned.  


While I would be surprised if this was the sole reason for Intel dropping support of Big Sur...if it is the sole reason, its a trivial fix and won't impact the support load at all.  in that case, I would hope that the powers that be might reconsider their decision given this new information.  


Anyway, hopefully this will be useful to some people out there - as unsupported (as I write this at least) a setup it might be.  




0 Kudos
5 Replies

Hi Metacollin,

Thanks for reaching out to us.

We are investigating your concern at our end. We will get back to you soon with an update.



It's an old note in the Release Notes that applied to the 19.1 and older PSXE compilers. We support ICC on Big Sur with the oneAPI 2021 compilers. No need to worry about macOS support for ICC.

The fix is really quite easier, and we'll add that to the Release Notes:

sudo xcode-select -s /Applications/

Then accept the license (only if you previously haven't) by:

sudo xcodebuild -license


Hi Metacollin,


We assume that your issue is resolved. If you need any additional information, please submit a new question as this thread will no longer be monitored.





This isn't working for me.  According to GROMACs I should be using `icc` to compile on MacOSX.  So I run the below:


CFLAGS="-syslibroot `xcrun --show-sdk-path` -isysroot `xcrun --show-sdk-path`" CXXFLAGS="-syslibroot `xcrun --show-sdk-path` -isysroot `xcrun --show-sdk-path`" cmake .. \
  -DMKL_LIBRARIES="/opt/intel/oneapi/mkl/2021.4.0/lib" \
  -DMKL_INCLUDE_DIR="/opt/intel/oneapi/mkl/2021.4.0/include" \
And I get
/usr/local/bin/icc -MD -MT CMakeFiles/cmTC_27000.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_27000.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_27000.dir/testCCompiler.c.o -c /Users/brian/tools/gromacs-2021.4/build_intel2/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_27000
/usr/local/Cellar/cmake/3.22.1/bin/cmake -E cmake_link_script CMakeFiles/cmTC_27000.dir/link.txt --verbose=1
/usr/local/bin/icc -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_27000.dir/testCCompiler.c.o -o cmTC_27000
ld: library not found for -lc++
I will try what @Ron_Green  suggested next and see if it works.  Is there also documentation that says the oneAPI 2021 actually supersede the 19.1 compilers.  If so I can make a post over to GROMACs to add a note in their docs.
Thanks to everyone.  Nice to see people working together!
So I tried compiling GROMACS with icc but it didn't work. I ran into dependencies issues below. I did not get these issues compiling with clang or gcc.
icc: command line warning #10006: ignoring unknown option '-fshow-sdk-path`'
icc: error #10172: dependency generation to a file requires dependency option
make[2]: *** [src/gromacs/CMakeFiles/tng_io_zlib.dir/__/external/tng_io/external/zlib/adler32.c.o] Error 1
make[1]: *** [src/gromacs/CMakeFiles/tng_io_zlib.dir/all] Error 2
make: *** [all] Error 2