I'm using this library in a PlatformIO project https://registry.platformio.org/libraries/joaolopesf/RemoteDebug
I ran into this issue
where the library has an obsolete include #include <hwcrypto/sha.h> that causes a compile error.
The solution is replacing this with the newer include <esp32/sha.h>.
While this is a valid solution, I don't like to have to edit library code to do it.
The question then, is if I can fix this from user code somehow?
something like #define <hwcrypto/sha.h> <esp32/sha.h>.
(That specific macro throws a different compile error).
Related
I am testing with a simple test program right now. It looks like below:
#include <iostream>
using namespace std;
int main() {
string s = "a b c d ";
remove(s.begin(),s.end(),' ');
}
When i build it with visual studio, it builds correctly and does not give any error. However if i try to build it with eclipse (mingw), it complains about the functions 'remove', as it should because the corresponding header is not included.
Is there a way to configure visual studio such that it will also complain and not auto-include headers or whatever fancy thing it is doing? I have already checked by disabling the option to use pre-compiled headers in visual studio project properties, and that doesn't help.
When you write a program that fails to include the proper headers, some toolchains may still just so happen to successfully build your program, because maybe their <iostream> happens to ultimately include the header you need (like <algorithm>).
That doesn't change the fact that your code is wrong. You're getting a build by chance.
You don't configure another toolchain to do that. You fix your code to include the correct headers.
So:
#include <string>
#include <algorithm>
The C++ Standard does not define, that a certain file needs to be included for the contained definitions to be able to be used.
It only defines in which files the specific functions are defined.
So if the specific implementation which You use includes everything through a file and You don't need to include anything else, than that is still allowed by the Standard.
So in one implementation, everything will compile, while in another errors will appear.
This is not controlled by the C++ Standard.
What You can do is file a bug to the implementors, and see if they agree that it's a bug. (In this case: https://github.com/microsoft/stl/issues)
I'm in VS2013, C++ console applications. I'm having a problem integrating boost into a large framework. If I try integrating them in a blank console application, they work fine. Once I include the "root" .h file of the framework (that includes "many" other .h files in the bargain), it breaks. These .h files are "polluting" the boost ones (and anything included after, with mixed results, and no, I can't just include boost ones first, that's not always an option unfortunately). I've found at least one root-level #define that interfered and caused a compile error, but I can't find some of the other conflicts that are causing run-time problems.
Specifically, my problem is this: how do I tell what symbols have been defined by .h files? And hopefully, which ones are then conflicting later? I tried googling, but couldn't find a tool for doing this.
Or is there some other method which can "isolate" them (my problem .h files), and yet still have them link correctly to the functions they're calling in other .dlls?
You can use g++ -E as a static code checking tool (without changing your toolset). It is able to tell you when something is redefined but not when a #define is used as another name (it would have no way to tell whether it was a real substitution or not).
If that's not the source of your problem then you may need to take a more holistic approach: Start changing your project's #define use to other constructs such as const and short functions. This will then allow the compiler to either resolve differences by overloading or complain that there are conflicts.
Including same header file again might have caused the problem,you can create a symbol for each header file so that if that header file is already included in some other header file it shouldn't be included.
#ifndef
#define __header_file_name_H
.....some code
#endif
I'm trying to have Cmake check if the file cxxabi.h is available. This file is from the c++ standard library, at least with g++. My current cmake commands look like this:
include(CheckIncludeFiles)
...
check_include_files(cxxabi.h HAVE_CXXABI)
if(HAVE_CXXABI)
...
else(HAVE_CXXABI)
...
endif(HAVE_CXXABI)
When this is executed, I get:
-- Looking for include files HAVE_CXXABI
-- Looking for include files HAVE_CXXABI - not found.
Although the file is available in /usr/include/c++/4.6.4/ and can properly be found by g++ when I compile a c++ code.
I suspect the macro check_include_files uses the C compiler instead of the C++ one to compile a small program that includes the required file, which of course fails since cxxabi.h is a C++ file.
Any idea how to solve that? (i.e. making the macro use the C++ compiler instead of the C one)
As edited in my original question:
Problem solved. There is a different macro for C++ headers, check_include_file_cxx, located in CheckIncludeFileCXX.
There exists another problem with CHECK_INCLUDE_FILES that I recently discovered with MinGW. The file tested was "ddk/ntapi.h". In the CMakeErr.log for this header I got a multiply messages like "DWORD - does not name a type" and so on for all MS types used in this header. Because of this reason the compilation fails and a requested header appears as "not found", whereas it is not true.
This happens because CheckIncludeFile.cxx contains only the requested header, and some headers in MinGW (and probably in the other APIs) does not include in its body all the list of required headers to be compiled in a standalone program that CMake creates.
The solution for this problem is to add absent basic includes into the CMAKE_REQURED_FLAGS, or as a third variable of CHECK_INCLUDE_FILE_CXX:
CHECK_INCLUDE_FILE_CXX("ddk/ntapi.h" VAR "-include windows.h")
I'm trying to build Boost 1.49.0 using GCC 4.7.0 (MinGW). I keep getting the following error message several dozen times:
c:\tools\mingw\bin../lib/gcc/i686-pc-mingw32/4.7.0/../../../../include/c++/4.7.0/cmath:1096:11: error: '::hypot' has not been declared
Line 1096 of cmath contains
using ::hypot;
cmath includes math.h which declares the hypot function as
extern double __cdecl hypot (double, double); /* in libmoldname.a */
In both files, a couple of lines after the ones quoted above, are identical statements for the hypotl function (except the type is long double instead of double) and that one seems happy.
Any ideas why I am getting this error?
The answer by #Praetorian correctly identifies the problem.
On the other hand, the Python headers are technically meant to come before any others.
In addition, sometimes the accepted solution does not work or is inconvenient in the build system, so I came up with an alternate solution.
Add the following flag to the call to g++:
-D_hypot=hypot
This makes it so that the harmful macro in the Python headers becomes a no-op, and the compilation error goes away.
Found the answer in this forum post. It seems that pyconfig.h has the following lines:
#if defined(__GNUC__) && defined(_WIN32)
// ...
#define hypot _hypot
// ...
#endif /* GNUC */
but cmath included with MinGW expects the function to be named hypot and not _hypot, which causes the compilation errors.
The fix was to include the following to my bjam command line's cxxflags option
bjam ... cxxflags="-include cmath "
This indicates that g++ should include the cmath header at the beginning of every source file.
As far as I can see this happens when compiling with MingW, using -std=c++0xx, and including Python.h before cmath. And note that cmath is included by quite a few other header files...
Note that the problem is not Boost specific. Complicating fact is that in my standard MingW - Visual Studio cross compilation setup, Visual Studio 2010 needs in Debug mode to have Python.h included before many other standard include files.
Solution is to include cmath first, followed by Python.h, so you get code like:
#include <cmath>
#include <Python.h>
#include < other standard headers >
The problem is identified correctly by #Praetorian.
In my case it only appears in one file.So I simply add
#define _hypot hypot before #include <Python.h>
and works.
Hope this can be enlightening.
Try looking at the preprocessed unit. I guess you'll find something like "#undef hypot".
I could solve this error in Code Blocks when I added the following path in the Linker
C:\Python36-32\libs
and put two libs on the link libraries: libpython36.a and python36.lib.
Add this line
#define _hypot hypot
at the first of your Python.h file that it is stored in your python installation directory. somewhere like C:\Python27\include.
I get the following errors when trying to build a small and simple project that includes <cmath> in Xcode:
cmath: '*' has not been declared
'::acos' has not been declared
In file included from /Xcode4/Projects/libraryLAFMath/Classes/libraryLAFMath.cp
In file included from /Xcode4/Projects/libraryLAFMath/Classes/libraryLAFMath.h
'::acos' has not been declared in /Xcode4/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.1.sdk/usr/include/c++/4.2.1/cmath
...
The error log complains about all the other math functions as well, sin, pow, etc, not just acos. I looked inside cmath source code and it references the globally defined corresponding math functions from math.h, ie ::acos etc. Since the root error complains about the non-existance of ::acos one would assume that math.h can't be found, but a) it exists, and b) I'd get a different error complaining that math.h can't be found.
The source code is as follows:
libraryLAFMath.cp:
#include "libraryLAFMath.h"
libraryLAFMath.h:
#include <cmath>
struct libraryLAFMath {
void test() {
double a = std::acos(0);
}
};
Now, I have another project from an outside source that uses cmath and compiles fine. I tried comparing build settings between these two projects but they are pretty much the same. I am using LLVM GCC 4.2 compiler, but get similar result when using GCC 4.2, so it's not a compiler settings issue I believe.
I'm new to Xcode development and any help is appreciated.
There is a file I have in my project named Math.h with a capital M, and it seems the compiler gets confused and tries to include Math.h instead of math.h.
I posted this answer on an alternate thread on the topic, but thought it worth including here as well:
I had this problem - it was driving me crazy but I tracked down the cause, and it was a little different than what I've seen reported on this issue.
In this case, the general cmath header (or math.h - the error and solution occur in C++ or C) had architectural environment switches to include architecture specific math subheaders. The architecture switch (environment variable) hadn't been defined, so it was punting and not actually including the headers that truly defined the math functions.
So there was indeed a single math.h or cmath.h, and it was included, but that wasn't enough to get the math functions. In my case, rather than define the architectural variable, I instead found the location of the correct sub math headers and added them to my compile path. Then the project worked!
This seems to be an issue that comes up a lot when porting Linux projects to OS-X. I'd imagine it might occur anytime a project was moved betwee platforms such that the standard library headers are arranged differently.