Table of contents
Problem Description
Question one
Clion on MacOS fails to compile when compiling the project, and appears
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/wchar.h:90,
from /usr/local/Cellar/gcc/11.2.0_3/include/c++/11/cwchar:44,
from /usr/local/Cellar/gcc/11.2.0_3/include/c++/11/bits/postypes.h:40,
from /usr/local/Cellar/gcc/11.2.0_3/include/c++/11/iosfwd:40,
from /usr/local/Cellar/gcc/11.2.0_3/include/c++/11/ios:38,
from /usr/local/Cellar/gcc/11.2.0_3/include/c++/11/ostream:38,
from /usr/local/Cellar/gcc/11.2.0_3/include/c++/11/iostream:39,
from /Users/macbookpro/Documents/CLion/Test/main.cpp:2:
/usr/local/Cellar/gcc/11.2.0_3/lib/gcc/11/gcc/x86_64-apple-darwin19/11/include-fixed/stdio.h:219:10: fatal error: _ctermid.h: No such file or directory
219 | #include <_ctermid.h>
| ^~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
_ctermid.hSuch an error is simply that the file cannot be found during compilation .
question two
When using CLion to debug the program, the element value in the STL container cannot be displayed, only some memory address values such as the start pointer and the end pointer can be displayed, and sometimes even when viewing through input variables, the expression will be displayed inexplicably expr failed, As a result, it is impossible to view the process that greatly affects the debugging (because the problem is temporarily solved, it cannot be demonstrated, look for a network diagram to explain, invade and delete)
the result I want:
the value of STL can be displayed during debugging.
Since problem one is derived from problem two, I will describe the problem-solving process in chronological order, and the final solution to the problem (not a positive solution for the time being) is placed in the last part.
Software platform version
- Xcode 10.1
- Clion 2021.3.4 Professional Edition
- MacOS 10.15.7 Catalina (Upgraded from 10.13 some time ago)
- GCC9、GCC11
- LLDB 13.0
The research process of the second question
If you want to solve the second problem, there are currently the following solutions:
Solution 1: Disable the GNU C++ library renderer in the settings
Someone on Zhihu replied that by disabling the GNU C++ library renderer in the settings, as shown in the figure below, remove the circled tick, then reopen the project, and there will be no problem with debugging again.
Don't know how useful this method is on Windows, but it doesn't work at all on MacOS.
Solution 2: Pass parameters and print by writing a function
By writing a function by hand, just like when printing, call the function expression to print out the desired element value. This method is really versatile, but when I want to view many elements in a container, it is very troublesome to pass parameters one by one to view.
Solution 3: Printing by using LLDB instructions
When debugging, use LLDB in the terminal to input the corresponding debugging instructions to print out. This method is also universal, but it requires a certain learning cost. You must be familiar with the instructions of the debugger, and the method is still not convenient enough. Every Each run requires typing commands to view the content.
Solution 4: Install GDB
I saw that someone said that if you use GDB in CLion on Mac, you can view the value of STL elements, but LLDB is not allowed. Because the GDB with MinGW used by Clion on my own Window can view the value of STL elements, I read a lot. The literature found that since 2017, people have reported that LLDB cannot view STL elements, and have not seen a perfect and easy-to-operate method for the time being, so they decided to use GDB to try.
CLion brought a 10.2 version of GDB, but I don’t know if it’s a problem with the upgraded version or what. When I used this GDB, a warning would always be reported, and then CLion would be stuck.
BFD: /usr/lib/dyld(i386:x86-64): unknown load command 0x34
BFD: /usr/lib/dyld(i386:x86-64): unknown load command 0x34
BFD: /usr/lib/dyld(i386:x86-64): unknown load command 0x34
In the end connect time out error, it was shown that debugging could not be performed, and the breakpoint could not be hit when setting a breakpoint, so try to install GDB additionally. This part refers to the tutorials on the Internet to install GDB, mainly referring to the tutorials on setting up gdb on macOS and using GDB on macOS10.14 in
2020. These two articles use the installation of GDB and set the signature certificate to make the computer trust it. After the installation is complete, in CLion, you can successfully see that a new gdb has been recognized at the box position in the figure below (because I uninstalled him later, it is not clearly displayed in the screenshot), and after selection, Clion will detect the version , but unfortunately: after selecting it, I found that my CLion only supports the GDB version up to 11.1, and brew installed the latest version 11.2 , so I fainted on the spot. In addition, there is another unfortunate news: After installing GDB, I directly replaced my original gcc9 with the latest gcc11 , pointed the compiler to the replaced gcc11 path, and used the original LLDB debugger, I tested whether it can Using it to compile, the result is of course unfortunate, and problem one appeared at this time.
homebrew
The introduction and research process of question 1
At this time, I thought that the latest gcc11 was not compatible with gcc9, so I uninstalled all gcc11 and reinstalled gcc9, but the error seemed irreversible and did not disappear, which meant that the gcc environment on my Mac was completely unusable, but it did not There is no detailed and accurate tutorial to solve this problem. The information on this problem on the Internet is almost 0. I only found a post on Stack Overflow reflecting this situation. _ctermid.h cannot be found on macOS Mojave 10.14.6
according
to As mentioned in the answer, I have tried, and now the tried methods are listed below
Method 1: Reinstall brew and gcc
Invalid, this has been tried just now, the error is irreversible.
Method 2: Install macOS_SDK_headers_for_macOS_10.14
According to the description, I need
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
to install, but I am 10.15 system, this directory is no longer in the system.
Method 3: Delete CommandLineTools and reinstall
use
(sudo) rm -rf /Library/Developer/CommandLineTools
Delete CommandLineTools, use
xcode-select --install
Do a reload. no effect.
Method 4: Install the latest CommandLineTools supported by the system version
This statement is supported by the fact that using
xcode-select --install
The installed CommandLineTools will not install the latest version of the tool, and always install the version of Xcode10. Now you need to install the tool with the highest version support to solve this problem. Since it is impossible to update directly from the App store, I downloaded the latest version 12.4 that is currently supported by MacOS 10.15 from
previous versions of Xcode . (You need to log in to the app store account.) If you need to check the Xcode version supported by the corresponding system, you can find it on this page. : Xcode system and corresponding version support After downloading and installing, enter the command in the terminal
xcrun --show-sdk-path
You can view the currently used SDK.
But unfortunately, although this method seems to work, it still doesn't work on my Mac.
Method 5: Set CMAKE_OSX_SYSROOT:PATH in CLion
After the method fails, there is no tutorial for this problem. I can only read a lot of information. Since I upgraded from version 10.13 to 10.15 some time ago, is it possible that it is because of the use of What about newer gcc versions causing the problem? So I checked some information, mainly collected in the following post:
After upgrading to Catalina 10.15, C programs cannot be compiled on Mac.
Most of the answers are that the header file folder has changed after updating to 10.15 system. However, the search path has not changed, so there will be situations where they cannot be found, just connect them to the corresponding folder.
But I checked those folders and found that my problem was not the same as theirs. At this time, I re-checked the error message and found such a message.
When compiling, cmake is actually looking for the SDK installed in Xcode, but the SDK he uses is not the SDK we chose in method 4, but in XCode. The old SDK, so I entered this folder to check
cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/
It was found that there is no header file in the header file of this SDK _ctermid.h.
After that, I checked the SDK in our updated CommandLineTools in Method 4
cd /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/
_ctermid.hI found that there are header files in it. At
this time, I probably understand the reason: because I have been using the old version gcc9 left over from 10.13, there is no _ctermid.hheader file before version 10.14, and when I put gcc brewAfter updating to version 11, it will search for the gcc version that is suitable for the current system by default due to the use of installation. In version 10.15, whether it is gcc11 or gcc9, they all need this header file. This is even if the version is changed back to The reason why the compilation still fails after returning to version 9.
So it can be seen that CLion is still using the old SDK. Can I change the SDK path specified by CLion so that he can use my newly installed SDK? CMakeCatch.txtAfter some searching, I found that the specified SDK path can be changed in the files in the project .
I changed the PATH in the above picture to the SDK path in the installed CommandLineTools, but this error occurred
unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd' for architecture x86_64
Good guy, the old pit was not filled and a new pit was opened. After a simple search for information, it is not easy to determine where the problem is, but I personally feel that it may be related to the chaotic C++ version on my Mac. Due to time The relationship between cost has not been studied in depth on this issue for the time being, and this method is invalid.
in conclusion
After trying the above methods, things have reached a deadlock for a while, and it seems that there is no way to find a way to solve this problem head-on. So I checked whether Xcode could still compile successfully with the last hope. I was pleasantly surprised to find that C++ files can be compiled normally in Xcode. It can be seen that Xcode contains a built-in C++ environment and is isolated from the outside world.
So is there a way to use CLion to use Xcode's built-in compilation system? I found this in settings.
In the option of the generator, the default is Ninja at the beginning, and there is an option of Xcode. When Xcode is selected, the program can be compiled and run normally. As shown in the figure, the STL container can also directly see the value when debugging. Question 1 And problem two is solved in a somewhat odd way.
related conjecture
To sum up, by selecting Xcode in CLion's CMake generator option, you can use a compilation system of Xcode, and even through the LLDB debugger, you can still display the element value of the STL container. However, this method does not solve the problem head-on. The C++ version of the entire Mac is still relatively confusing. Due to the time cost, I did not continue to explore and solve the problem head-on. However, based on the methods tried so far, the following conjectures can be made about the possible ways to solve the problem head-on:
In method 4 to solve problem 1, although CommandLineTools is updated to version 12.4, Xcode is still the ancient version 10.1 at 10.13. Currently, the highest Xcode support version for MacOS 10.15.7 is 12.4, because CommandLineTools will still be updated after CommandLineTools is updated. The error is reported because the SDK used by CLion is not the same as the SDK of CommandLineTools, but whether it will match the version of CommandLineTools through the upgrade of Xcode, and then update the default SDK used by CLion so that it can be executed under the current system Woolen cloth? This aspect should be worth exploring further.