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.
Related
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).
I've found that a small C++ project, with no dependencies, won't compile under Cygwin with either GCC or Clang. Under Ubuntu there are no problems; and I've been working with this code for a couple of years. I'll introduce a MWE.
The problem arises when including a header in a subdirectory, which itself includes another header, found in that same subdirectory, but specified with the subdirectory in the path provided to the include directive. Executing the following commands can replicate the error:
mkdir foo
echo \#include \"foo/includes.hpp\" > inc.hpp
echo \#include \"foo/bar.hpp\" > foo/includes.hpp
touch foo/bar.hpp
g++ -c inc.hpp
On 64-bit Ubuntu 18.10, the final GCC (or Clang) invocation will produce no errors. On 64-bit Cygwin under Windows 10, the following error message is displayed.
In file included from inc.hpp:1:0:
foo/includes.hpp:1:10: fatal error: foo/bar.hpp: No such file or directory
#include "foo/bar.hpp"
^~~~~~~~~~~~~
compilation terminated.
Can anyone shed some light on the issue? (By the way, I myself do well understand how to properly include header files - this is about the difference between Cygwin and Ubuntu.)
foo/includes.hppshould have local includes if you use "".
That would be:
#include "bar.hpp"
The specification for what paths are used for searching headers is custom for all compilers, although includes with "" should be considered as local for the file where you have the include, not the one that you are compiling.
Basically, it's:
look in the current folder of the current header being processed for a file with that name
use the same paths as <>after
Of course, as I've said, this could change for a new compiler one day. But it is quite safe to assume that this is the behavior for all compilers (What is the difference between #include <filename> and #include "filename"?).
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.
I'm experiencing an extremely weird problem in a fresh OSX 10.4.11 + Xcode 2.5 installation. I've reduced it to a minimal test case. Here's test.cpp:
#include "macros.h"
int main (void)
{
return 1;
}
And here's macros.h:
#ifndef __JUST_TESTING__
#define __JUST_TESTING__
template<typename T> void swap (T& pT1, T& pT2)
{
T pTmp = pT1;
pT1 = pT2;
pT2 = pTmp;
}
#endif //__JUST_TESTING__
This compiles and works just fine if both files are in the same directory. HOWEVER, if I put macros.h in /usr/include/gfc2 (it's part of a custom library I use) and change the #include in test.cpp, compilation fails with this error :
/usr/include/gfc2/macros.h:4: error: template with C linkage
I researched that error and most of the comments point to a "dangling extern C", which doesn't seem to be the case at all.
I'm at a complete loss here. Is g++ for some reason assuming everything in /usr/include/gfc2 is C even though it's included from a .cpp file that doesn't say extern "C" anywhere?
Any ideas?
EDIT : It does compile if I use the full path in the #include, ie #include "/usr/include/gfc2/macros.h"
EDIT2 : It's not including the wrong header. I've verified this using cpp, g++ -E, and renaming macros.h to foobarmacros.h
G++ may well indeed be assuming that everything in /usr/include is C. Try compiling your code with -E and studying the line markers in the preprocessor output:
g++ -E test.cpp | grep '^#'
You'll likely see things like
# 1 "/usr/include/gfc2/macros.h" 1 3 4
The 4 is the preprocessor hinting to G++ that it should wrap everything in extern "C", on the supposition that your platform's ancient header files in /usr/include predate C++. See Preprocessor Output in the CPP manual.
These days G++ mostly ignores this hint, because most platforms' C headers are no longer ancient. See the NO_IMPLICIT_EXTERN_C target macro in the GCC Internals manual. But it may be that this old version of Xcode has GCC configured without NO_IMPLICIT_EXTERN_C and thus is listening to the preprocessor's hint. (This is set when GCC itself is built -- I don't think there's a command-line switch to override it.)
You may be able to work around this by wrapping the contents of your header file in extern "C++".
This is a shot in the dark, but is there another file named macros.h somewhere under /usr/include or in your GCC installation? GCC has a facility for wrapping headers, called #include_next, which might be the cause of your problem.
One thing you can do to disambiguate your macros.h from any other macros.h in the include path is to include it as gfc2/macros.h. This way, the compiler will search every directory in the include path for a subdirectory named gfc2 containing a file named macros.h, reducing the chance of a collision. It also prevents you from having to add /usr/include/gfc2 to the include path.
BTW, #include "file.h" searches the current directory first. To skip that and go straight to the include path, use #include <file.h>:
#include <stdio.h>
#include <gfc2/macros.h>
Another approach is to choose a filename that is more likely to be unique, like gfc2macros.h.
Well, it really looks weird...
How does XCode calls g++?
I don't think g++ spontaneously decides that an include file has C linkage just because it's in a different directory. Did you try to compile your project by hand?
Try "g++ main.cpp -I/usr/include/gfc2/". If this solves your problem than it's not g++. Maybe does XCode precompile headers?
Have you tried not changing the test.cpp file at all, but instead when you compile also say:
-I/usr/include/gfc2/
You can see where g++ is looking for includes with the verbose flag:
g++ -v -o test test.cpp
And this will just run the preprocessor and show what is actually included in the file and compiled:
g++ -E test.cpp | less
If the wrong files are getting included (or your header is getting wrapped in another, as bk1e suggests) you'll be able to find out with that output.
I just ran into this issue as well when compiling a C++ project that we normally build on 10.5 and 10.6 (Xcode 3.0+) on a 10.4 PPC machine with Xcode 2.5 installed. It looks as if the preprocessor treats anything added to the gcc include path with '-isystem' as if it should be "extern C". Changing '-isystem' to '-I' resolved the issue.
I'm compiling a project in XCode where MySQL++ in included and linked to. For some reason, I keep getting the following compiler error:
'assert’ was not declared in this scope
originating from cpool.h, a header file that's part of MySQL++. Does anyone know why this is being triggered?
EDIT: For reference, MySQL++ was installed via Macports.
The most obvious answer would be that "assert.h" is not being included or is not being found in your include path. Another explanation is that the assert macro has been undefined at some point after the header was included.
Edit: Since you say that assert.h is included, and we'll assume for the moment that it's being found since it's a standard header, then that leaves us with the last possibility I stated above i.e. that the macro has been undefined.
Since cpool.h itself will not be doing this it must be the case that assert.h is included earlier either by yourself or indirectly by another 3rd party header and the undefining happening between this and your inclusion of cpool.h. This can easily be tested by moving your cpool.h include to the top of your file.
In c++ adding cassert header should fix your problem.
#include <cassert>
It could be that another library in your include path has a different "assert.h" file, and you are unknowingly including that one instead of the system's standard <assert.h>.
I ran into this issue when writing an application that uses gstreamer on Mac OSX. It turns out that gstreamer's include directory (/Library/Frameworks/GStreamer.framework/Headers) includes a file "assert.h", which is non-standard and an unsuitable replacement for the real assert.h. When I added -I/Library/Frameworks/GStreamer.frameworks/Headers to my compilation command, suddenly my sources, which just said "#include <assert.h>" where including the gstreamer version. This caused my compilation to fail with the same error you were getting.