trns1997 commented on code in PR #11301:
URL: https://github.com/apache/nuttx/pull/11301#discussion_r1415914706
##########
include/wchar.h:
##########
@@ -57,6 +57,8 @@
* Reference: Opengroup.org
*/
+#define _LIBCPP_WCHAR_H
Review Comment:
to prevent the following error that we've been having all along:
```
/home/thomas/nuttxspace/nuttx/include/libcxx/cwchar:117:5: error: #error
<cwchar> tried including <wchar.h> but didn't find libc++'s <wchar.h> header.
This usually means that your header search paths are not configured properly.
The header search paths should contain the C++ Standard Library headers before
any C Standard Library, and you are probably using compiler flags that make
that not be the case.
117 | # error <cwchar> tried including <wchar.h> but didn't find
libc++'s <wchar.h> header. \
```
It was either this or creating a patch file in libcxx. I think this might be
better but fundamentally llvm added this check and explained why they added
this here :
https://github.com/llvm/llvm-project/commit/8cedff10a18d8eba9190a645626fa6a509c1f139
.
The guy who added this check says the following:
```
[libc++] Diagnose when header search paths are set up incorrectly
An issue I often see in codebases compiled for unusual platforms is
that header search paths are specified manually and are subtly wrong.
For example, people will manually add `-isystem
<some-toolchain>/usr/include`,
which ends up messing up the layering of header search paths required by
libc++ (because the C Standard Library now appears *before* libc++ in
the search paths). Without this patch, this will end up causing
compilation errors that are pretty inscrutable. This patch aims to
improve the user experience by diagnosing this issue explicitly.
In all cases I can think of, I would expect that a compilation error
occur if these header search paths are not layered properly. This
should only provide an explicit diagnostic instead of failing due
to seemingly unrelated compilation errors.
Differential Revision: https://reviews.llvm.org/D131441
```
And i feel that we're technically falling in this case where we are setting
the header search paths manually. Now are we doing it wrong, i am not sure :) .
But this modification is a work around.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
