I wrote a c++ program using boost library in Xcode. Here is my code. It is very simple.
#include <iostream>
#include </usr/local/include/boost/math/special_functions/beta.hpp>
using namespace std;
using namespace boost::math;
int main (int argc, char * const argv[])
{
double a = 100.0;
double b = 100000.0;
double x = 0.3;
double result = beta(a, b, x);
cout << result << endl;
return 0;
}
But when I tried to build it in the Xcode, there popped up a lot of errors related to the library linking stuff. I noticed that the compiler that Xcode was using was "System Default: gcc 4.2". And all other options are gcc or LLVM gcc (I have no idea what this is).
I later tried to compile the file simply using terminal. Weird thing happened. If I compile it with g++, without any extra flags, the compilation completed successfully and the the program could be ran normally; but if I compile it with gcc, there are pages of errors.
So, to sum it up, while using g++, everything is OK; while using gcc, everything is not OK. Since the Xcode is using gcc, the program could not be compiled using Xcode.
(And I kind of need to use the Xcode because this is just a test program, I actually have a much bigger project to handle and I depend on the debugger of Xcode.)
So my question is, WHAT THE HELL is the difference between gcc and g++? Or how can I change the compiler of Xcode to g++?
gcc is a C compiler.
g++ is a C++ compiler.
You're trying to compile C++, ergo, you need to use a c++ compiler.
Googling "Using XCode for c++" brings up lots of results, but this one seemed fairly straightforward and had pictures:
https://www.cs.drexel.edu/~mcs171/Wi07/extras/xCode_Instructions/index.html
The gcc command compiles C files (although you can use -libstdc++) to link C++ files as well but I don't recommend it.
The g++ command works for C++ files which is why it worked in your case.
For XCode you have to change the compiler from GCC to G++ for it to successfully work.
Related
I'm trying to integrate CUDA to an existing aplication wich uses boost::spirit.
Isolating the problem, I've found out that the following code does not copile with nvcc:
main.cu:
#include <boost/spirit/include/qi.hpp>
int main(){
exit(0);
}
Compiling with nvcc -o cudaTest main.cu I get a lot of errors that can be seen here.
But if I change the filename to main.cpp, and compile again using nvcc, it works. What is happening here and how can I fix it?
nvcc sometimes has trouble compiling complex template code such as is found in Boost, even if the code is only used in __host__ functions.
When a file's extension is .cpp, nvcc performs no parsing itself and instead forwards the code to the host compiler, which is why you observe different behavior depending on the file extension.
If possible, try to quarantine code which depends on Boost into .cpp files which needn't be parsed by nvcc.
I'd also make sure to try the nvcc which ships with the recent CUDA 4.1. nvcc's template support improves with each release.
all.
Compiling simple stuff using the gcc toolchain for several years, today I ran against a curious phenomenon.
I installed Kubuntu 14.04 to a common desktop i686 machine with gcc 4.8.2 in it. But then, trying to build some well coded stuff pulled out from my local repository, I ran against tons of 'undefined reference to' messages. The code compiles, links und runs well under Ubuntu 11.04 / gcc 4.5.2.
I checked the linking process (by -Wl,--verbose to gcc), think it works. It finds all libraries I specify in the link command. An objdump -t myLib.so brings exactly the symbols I'd expect - but the linker doesn't see them.
Checking the pthread library also brings according symbols, except they are suffixed with some #GLIBC... stuff. Didn't check linker/loader tricks so far.
A sample like
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
static void *fooo (void *xxx) {
char *txt = (char*)xxx;
printf("My job is to print this :'%s'. Bye now!\n", txt);
return 0;
}
int main (int argc, char *argv[]) {
pthread_t thd;
pthread_create(&thd, NULL, fooo, "A POSIX thread");
sleep(1);
return 0;
}
runs very well on the old system just saying
gcc -l pthread fooo.c && ./a.out
but breaks at the linking step with 4.8.2.
Any idea would be very welcome.
.M
Thanks to sfrehse, JoachimPileborg et al!
Indeed, success depends on argument order. I knew this fact for static linking, but it is new in processing of shared objects with gcc.
Does someone know what the background of this improvement is? It breaks innumerable build processes, and I guess thousands of tomatoes are being made ready against gcc.gnu.org .....
.M
I have:
-cygwin 1.7.25 on windows 7/32bit
-g++ --version --> g++ (GCC) 4.8.2
-libstdc++.a --> gcc-g++-4.8.2-1
Tried to make a c++
Hello World:
#include <string>
int main()
{
std::string s = "123";
int i = std::stoi(s);
}
compiling gives:
$ g++ -std=c++11 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:6:10: error: ‘stoi’ is not a member of ‘std’
int i = std::stoi(s);
I searched for hours but I still could not find a solution. What's the issue here?
That's a bug, possibly an incomplete port of some library code to cygwin (it's a cplusplus11 feature) - some stuff has to be changed after all. Make sure to report it.
The solution is easy of course: #include <cstdlib> strtol(s.c_str(),0,10);
www.cplusplus.com/.../strtol
A similar mingw bug is mentioned also here
std::stoi doesn't exist in g++ 4.6.1 on MinGW
I have the same problem yesterday. "error: 'stoi' is not a member of 'std'."
First, I made sure c++11 was enabled. Then, I updated the g++ compiler to the newest version. After that, this error disappeared.
The compiler is not being taken seriously. On windows your best bet is to probably use visual studio, as it is always kept up to date . The bug here is that the macro defs are wrong to begin with. The problem starts from iomanip.h and iosbase . So they would have to changed all of there code. There are user made patches for this but I would not trust them at all, as they may contain even more bugs then the original copies. But it's up to you , I just stick with visual studio express edition.
stoi works correct only on mingw64 for me.
If you use Codeblocks, don't forget to check if your projects compiler is set to mingw64.
Well, I am working with -std=c++98, not -std=c++11 but I solved it with the following:
int i = std::atoi(input.c_str());
atoi() is waiting for c type null-terminated string, c_str() makes it null-terminated char*. To use atoi I also() added the following library:
#include <cstdlib>
my system is:
Ubuntu 22.04.1 LTS
I'm trying to compile an application that utilizes cstdint. Since Apple deprecated the gcc, I wanted to try compiling it with clang, but i get the error:
fatal error: 'cstdint' file not found
I know that the gcc 4.6.2 version has the option for -std=c++0x, to include the library, but since the os x version is 4.2 that's not much of an option here. Any suggestions on how I can move forward? I have tried to install 4.6.2, but ran into a variety of issues when compiling some of the needed libraries before building gcc.
Presumably, you have the source code to this application, so you can modify the headers to include the correct cstdint header, as Clang 3.0 (which Lion's tools come with) does have the header.
Quick Solution
The header is under the tr1 directory, so you will want to do either of these includes:
#include <tr1/cstdint>
Or
#include <stdint.h> // which will use the C99 header
Longer, boring explanation
After doing some additional reading since I remember you can do this without the tr1 directory:
By default, you are going to be including C++ headers from /usr/include/c++/4.2.1, which are the GNU GCC headers. /usr/include/c++/4.2.1/tr1 includes the TR1 header files, like cstdint.
The alternative method is to compile using the Clang++ frontend and passing the -stdlib=libc++ flag, which will use the headers from /usr/include/c++/v1, which are Clang's C++ header implementations. It has cstdint.
Example:
// file called example.cxx
#include <tr1/cstdint>
int main() {
// whatever...
}
Compile this with:
g++ example.cxx
or
clang++ example.cxx
And it will do what you want.
If you don't want to use the tr1 version (which is roughly the same, if not exactly):
// file called example.cxx
#include <cstdint>
int main() {
// stuff
}
This is compiled like this:
clang++ -stdlib=libc++ example.cxx
Though if you use -stdlib=libc++, it means you're linking to Clang's C++ library libc++, rather than GCC's libstdc++.
I have a mixture of c and c++ files compiling under g++. As explained in:
What is the difference between g++ and gcc?
The c files are being compiled as c++ with the g++ command line. Not huge problem but migrating over to gcc will allow th c files to compile as c files and the c++ file to compile as c++.
What -I includes or -L libraries do I need to add to the gcc command line, that the g++ command line is including by default?
You shouldn't need to add any includes or libraries beyond what you already have.
Whatch out for C functions being called from C++ code - you need to tell the C++ compiler those are C functions so the program is linked correctly and works.
The standard practice is to add the following directives to all your C headers being included in C++ files:
#ifdef __cplusplus
extern "C" {
#endif
... C header contents go here ...
#ifdef __cplusplus
}
#endif
More info here: http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
You shouldn't need to add any. If it's using C++ it should automatically bring in C++ libraries.
If not, you'll want -lstdc++ (and if you're still getting undefined references, -lc for the libc). Don't forget -lm if you use math functions.
GCC can determine which language a file is in based on the file extension. However, GCC does not automatically link in run time support for any language other than C. In practice that means you can compile C++ programs using gcc instead of g++ but you'll need to add the -lstdc++ directive:
#include <iostream>
int main()
{
std::cout << "Hello world\n";
}
g++ hello.cc
gcc hello.cc -lstdc++
More accurately, you will need to specify -lstdc++ if you you use the standard library, exceptions, operator new, or RTTI. For instance, try compiling the following without -lstdc++:
int main()
{
try {
throw 1;
}
catch (int i)
{
return i;
}
}
Please note that STL containers (including std::strings) use operator new by default. Strictly speaking you should be able to use the algorithms (std::min, std::find_first_of, etc.) binders and a few other things in the standard library without -lstdc++ but for the most part you might as well include it (the linker will ignore any libraries that you don't actually link to).
Why not compile the c objects with gcc and the c++ with g++ and then when you link, link using the g++?