I have a Qt C++ application that compiles fine with the MSVC compiler. Now I'm trying to compile the same application with MinGW so that I can eventually port it to Mac OSX. However, when doing so I'm getting an error on all the standard includes:
#include <algorithm>
#include <ctime>
#include <map>
#include <sstream>
#include <vector>
And the compiler outputs:
..\trunk\stable.h:29:21: error: algorithm: No such file or directory
..\trunk\stable.h:30:17: error: ctime: No such file or directory
..\trunk\stable.h:31:15: error: map: No such file or directory
..\trunk\stable.h:32:19: error: sstream: No such file or directory
..\trunk\stable.h:33:18: error: vector: No such file or directory
I really don't understand what could be causing this issue. Any suggestion?
This is one of the more common errors you will see if your source is C++ but is being compiled as C.
This in turn can happen if the source uses .C (note capital C) extension for C++ files. If the source is used in a case-insensitive file system (like all of the windows ones generally) then make probably won't be able to properly tell whether to compile them as C or C++.
By default, make (including the mingw version) will compile C++ source from extensions .C, .cc and .cpp. (This page has the details).
You have 3 options:
rename your sources to one of the above extensions. generally .cc and .cpp are the easiest to work with.
if ALL of the sources in the makefile, you can go CC=mingw32-g++ mingw32-make -f Makefile.Debug
you can add this to the makefile or one of the included files:
%.o: %.c++
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c -o $# $<
but this will only work if the makefile(s) haven't changed the rules for compilation.
Related
I'm trying to use a couple of functions from the Boost Math library in some C++ code using the G++ compiler but I've been unsuccessful. This is on macOS.
I downloaded and extracted the Boost tar.gz from here and placed it into my source folder.
Within my C++ I've tried
#include "boost_1_63_0/boost/math/distributions/chi_squared.hpp" and
#include <boost_1_63_0/boost/math/distributions/chi_squared.hpp>.
The quotation version partially works but the chi_squared.hpp file includes fwd.hpp using the bracket (#include <...>) notation and that breaks my compilation with error In file included from main.cpp:9: ./boost_1_63_0/boost/math/distributions/chi_squared.hpp:12:10: fatal error: 'boost/math/distributions/fwd.hpp' file not found #include <boost/math/distributions/fwd.hpp>.
To compile I've used an assortment of commands, all unsuccessfully:
g++ -L /boost_1_63_0/boost/math/distributions main.cpp
g++ -I"/boost_1_63_0/boost/math/" main.cpp
g++ -I "/boost_1_63_0/boost/math/" main.cpp
g++ main.cpp -lboost_math
What is the correct include statement and G++ command that I need to use?
Resolved using
#include "/Users/[me]/[project_dir]/boost_1_63_0/boost/math/distributions/chi_squared.hpp"
and
g++ -I/Users/[me]/[project_dir]/boost_1_63_0/ main.cpp
I already asked how to call a C++ constructor from a C file in How to call a C++ constructor from a C-File. Now when I successfully apply these methods suggested there, I receive an error
fatal error: string: No such file or directory compilation terminated
this error message points to the line: #include <string> in a header of a .cpp file.
I already found out that <string> is used by c++/g++ and <string.h> by c/gcc. Well the problem got clearer, when I checked the console output and there I can see, the (.cpp) file with the error was called by the gcc, which actually expects the <string.h> but that's not my intention - I need to compile it with the g++.
Now my question is: Can I force Eclipse to use a specific compiler? Here, for example just g++ (I heared it is capable of C-code too.) - Or even better, is there a way to chose the compiler for each directory in the workspace ?
Thanks for your advises
Answer respecting the wish of being able to specify the compiler for every subfolder:
What you are searching is probably a makefile project. That allows you to specify the toolchain, being for example the preprocessor, compiler and linker. g++ is an example for such a toolchain, as much as clang++ would be.
You can generate such a project in eclipse, writing the makefiles by hand, or use some build environment, such as CMake, which I would recommend for better portable code.
Both solutions would allow you to specify the compiler, as well as the compile flags, for every single directory of your project, if you wished so.
Writing a makefile for your existing C/C++ project can be achieved by completing the following steps:
in the folder where your source file is, right click and create a new file. New > File
name it makefile and click Finish
The new makefile should pop up in the editor and can be filled like follows:
makefile:
all: executable_name
clean:
-rm main.o executable_name[.exe on windows] executable_name
executable_name: main.o
g++ -g -o executable_name main.o
main.o: main.cpp
g++ -c -g main.cpp
Change Project's Setting can force eclipse to compile using g++:
I recently cross compiled Boost library for PowerPC and generated the thread and system library. Then to test the library on my target, tried one of the sample code in Boost library and tried to build the binary using the previously built boost library but got the below compilation errors
.
.
GNU C++ version 4.2.2 (powerpc-linux)
compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.3 2.96-113).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128176
Compiler executable checksum: dd5a9a41381fa3b9978b2738b80f5a75
In file included from /shared/deps/powerpc/include/boost/config/platform/linux.hpp:15,
from /shared/deps/powerpc/include/boost/config.hpp:53,
from /shared/deps/powerpc/include/boost/thread/detail/platform.hpp:14,
from /shared/deps/powerpc/include/boost/thread/thread.hpp:12,
from helloworld.cpp:7:
4.2.2/cstdlib:106: error: '::div_t' has not been declared
4.2.2/cstdlib:107: error: '::ldiv_t' has not been declared
4.2.2/cstdlib:109: error: '::abort' has not been declared
4.2.2/cstdlib:110: error: '::abs' has not been declared
4.2.2/cstdlib:111: error: '::atexit' has not been declared
4.2.2/cstdlib:112: error: '::atof' has not been declared
4.2.2/cstdlib:113: error: '::atoi' has not been declared
.
.
Below is the sample program given with Boost library
#include <boost/thread/thread.hpp>
#include <iostream>
void helloworld()
{
std::cout << "Hello World!" << std::endl;
}
int main()
{
boost::thread thrd(&helloworld);
thrd.join();
}
Make file:
CC=ppc_4xx-gcc
CPP=ppc_4xx-g++
CFLAGS=-c -g -Wall -static -v
LDFLAGS_TARGET=-$(LDFLAGS_PowerPC)
LIBS_TARGET=$(LIBS_PowerPC)
CPPFLAGS=$(CPPFLAGS_COMMON) $(CPPFLAGS_PowerPC)
INCLUDES=-I/opt/ELDK/4.2/ppc_4xx/usr/include/ -I. -I/opt/ELDK/4.2/ppc_4xx/usr/src/u-boot-1.3.1/board/xilinx/common/ -I/opt/ELDK/4.2/ppc_4xx/usr/src/linux-2.6.24/arch/powerpc/boot/ -I4.2.2/
DEPSROOT=/shared/deps
COMMON_INCLUDES = $(DEPSROOT)/common/include
PowerPC_INCLUDES=$(DEPSROOT)/powerpc/include
CPPFLAGS_PowerPC=-I$(PowerPC_INCLUDES)
CPPFLAGS_COMMON = -I$(COMMON_INCLUDES)
PowerPC_LIBS=$(DEPSROOT)/powerpc/lib
LDFLAGS_PowerPC=-L$(PowerPC_LIBS)
LIBS_PowerPC=-lboost_thread -lboost_system
all: helloworld
helloworld: helloworld.o
$(CPP) -g helloWorld.o -o helloworld -static
helloworld.o: helloworld.cpp
$(CPP) $(CFLAGS) $(CPPFLAGS) $(INCLUDES) $(MODS) helloworld.cpp
clean:
rm -rf *.o helloWorld
The error is in the file cstdlib in the below location
.
.
_GLIBCXX_BEGIN_NAMESPACE(std)
using ::div_t;
using ::ldiv_t;
using ::abort;
.
.
The macro _GLIBCXX_BEGIN_NAMESPACE is setting the namespace as std with certain visibility. I am new to this so couldn't follow it completely.
Has anyone faced similar problem ? I read in some posts that the namespace is missing causing this error but I am not sure if that's the issue in my case.
EDIT
I got more information on the problem. First I thought the problem was with the namespace, so I manually changed the namespace to std but it didn't help. Then I added the definition of the structure div_t just before the statement using ::div_t; and one of the errors decreased (i.e the statement was compiled). So the problem was with the missing definition of div_t structure.
Now the structure div_t is defined in the file stdlib.h which is included in the current file cstdlib. When I did a locate on the file name stdlib.h, I found the below references
/opt/ELDK/4.2/ppc_4xx/usr/include/stdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/include/bits/stdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/include/c++/4.2.2/tr1/stdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/include/freetype2/freetype/config/ftstdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/src/linux-2.6.24/arch/powerpc/boot/stdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/src/linux-2.6.24-xenomai/arch/powerpc/boot/stdlib.h
Only the first file has the definition of div_t and not the others. The file under discussion cstdlib is in the folder ../include/c++/4.2.2/, now if the file stdlib.h is included here which one of the multiple stdlib.h is included ? The location /opt/ELDK/4.2/ppc_4xx/usr/include is present in my include path.
BTW how do I know which file is being included ?
The problem was the same as Cross Compile Boost library for PowerPC architecture. The include path which had the definition of dev_t was omitted and the next include path was used. Unfortunately it also had a file stdlib.h which didn't have the definition of dev_t structure. I created soft links and made sure the compiler picked up the correct stdlib.h file.
I have this C++ file (let's call it main.cpp):
#include <string>
#include "main.y.c"
void f(const std::string& s) {
yy_switch_to_buffer(yy_scan_string(s.c_str()));
yyparse();
}
The file depends on main.y.c, which has to be generated beforehand by means of bison util. In other words, I can't compile main.c file if I forget to run bison main.y before it. And it's perfectly OK, this is how I want it. Now I'm trying to build .d file from Makefile, using this command:
$ c++ -MM main.c > main.d
main.cpp:2:10: error: main.y.c: No such file or directory
I fail here, since main.y.c is not ready yet. I think that I should somehow quote my #include directive in the main.c file to make it invisible for c++ -MM process.
This sounds like a job for a makefile. You can set the dependencies such that main.c depends on main.y.c, and main.y.c has a rule to build it from the bison code.
You can indicate in your makefile that main.c depends on main.y.c so that it'll run the bison process before it tries to compile main.c.
As an alternative (which I think is probably not what you want to do) is that you can have your makefile pass a macro to the compiler to indicate whether or not main.y.c exists and use an #if directive to include (or not) main.y.c.
#if EXISTS_MAIN_Y_C
#include "main.y.c"
#endif
I'm trying to compile a third-party library, but g++ is complaining about the following line:
typedef boost::shared_ptr<MessageConsumer> MessageConsumerPtr;
The strange thing is, there is no #include directive in the file - and it is clearly supposed to be this way; there are about 60 files with the same (or very similar) issues. Clearly if there was an #include directive referencing the relevant boost header this would compile cleanly.
My question is: how can I get g++ to somehow automagically find the relevant symbol (in all instances of this issue, it is a namespace that can't be found - usually std:: or boost::) by either automatically processing the relevant header (or some other mechanism).
Thanks.
Edit
My current g++ call looks like:
g++ -fPIC -O3 -DUSING_PCH -D_REENTRANT -I/usr/include/boost -I./ -c MessageInterpreter.cpp -o MessageInterpreter.o
You can use the -include command line option:
g++ -include boost/shared_ptr.hpp ...
From the man page:
-include file
Process file as if "#include "file"" appeared as the first line of
the primary source file. However, the first directory searched for
file is the preprocessor's working directory instead of the
directory containing the main source file. If not found there, it
is searched for in the remainder of the "#include "..."" search
chain as normal.
Create your own wrapper .h file that includes the boost .h and then the broken .h .
Or (very fragile) ensure that you precede every use of the broken .h with boost .h .
Perhaps the third-party library is designed in such a way that you should always include a certain "main" header file in order to get the dependencies right.
Otherwise, you can add #include <boost/shared_ptr.hpp> before including the third-party header file that is giving the error message.