I'm fairly new to C++ and writing makefiles. I'm trying to compile a C++ project with the "canonical" structure described here with a makefile. I'm running into a problem where the compilation is failing because it can't find the headers due to using <brackets> instead of "quotes" when including the headers.
How do I tell the compiler where to find the headers in the project?
Usually, you would use the -I option, followed by a relative or absolute path to the directory where the headers are.
For example:
gcc -c src/foo.c -o obj/foo.o -I src
(However, compiler options are not part of the C++ standard, so it depends on what compiler you are using, and you did not say.)
Related
I am working on an Autools front-end for a C++ library. It looks like Libtool is adding C source files to the project and its causing a fair amount of trouble on some platforms. We think its causing unexplained crashes like Message “During startup program terminated with signal SIGKILL” from GDB.
The C source files cause trouble for several reasons. First, we only query CXXFLAGS and set AM_CXXFLAGS; and we don't do anything with CFLAGS or AM_CFLAGS. Second, C files need additional options in a C++ project, like -frtti and -fexceptions under GCC and options like -qrtti under IBM XL C/C++ compiler. Its not clear to me if libtool is adding the necessary options. Third, the C source files added by Libtool need additional Posix options on platforms that use Newlib, like Cygwin and MSYS. Our source files don't need the options.
I'd like to force Libtool to use C++ instead of C but I have not been able to locate an option or method to do so. I think the easiest path would be for Libtool to use lt-<some file>.cpp and CXXFLAGS rather than lt-<some file>.c and CFLAGS but I can't figure out how to do it.
How do we tell Libtool to use C++ and not C?
A related problem is How to disable C compiler in C++ Autotools project, but it only ask to use the C++ compiler for feature testing.
You could add the C compiler options you mention to the CFLAGS env var before compilation. Do you see any reasons why this would not work?
My situation is I have a library that doesn't have a "lib" prefix. I'd like to link against it, and I can't recompile it (it's actually a Python module).
Now, if you use the '-l' flag with GCC or clang, then the lib prefix is automatically added and the library is not found. For GCC, I can use '-l:mylib.so' to get it to link against an arbitrary file.
However, this doesn't work for clang. Is it possible to get clang to link against a particular library without the 'lib' prefix?
This answers the question, but from a somewhat different angle. See the related question C++ 11 code compiles with `clang++`, but not with `clang -x c++`.
The gcc documention states:
Object files are distinguished from libraries by the linker according to the file contents.
This does not work if you use clang++ -x c++. Instead, the library file is taken as a C++ source file, and this generates a million or so compile errors. And you can't put the library file before the -x c++, because the needed symbols won't be linked in.
One obvious solution is to rename your source files to have a .cpp extension, so the -x switch is unnecessary (or use symbolic links). But this might be a pain to add to your build system.
Another solution, directly related to the OP's question, is to specify the library via the flags:
-L. -l:mylib.foo
If the library is not in the local directory, change the dot . accordingly.
Every time I want to use CURL in one of my C++ programs, I have to add the flag -lcurl as a flag onto g++. This can be especially annoying when working with Eclipse. If /usr/include/curl/curl.h exists, what do I need to do to have CURL always be within the include path for g++?
tl;dr: you have to add the flag.
The linker needs libcurl, not the compiler. The compiler needs the header; the linker needs the lib.
To simplify things quite a bit, the header file tells the compiler that the declarations will be defined later. libcurl is what actually defines them.
The linker does not guess-and-check what to link against (doing so would be a horrible idea). You must explicitly tell it what to link against (except for the default libs). In particular, the linker has to know to use libcurl to find the declarations that curl.h laid out. Without libcurl, the linker is missing functions and thus cannot produce a complete binary.
I'm not familiar with Eclipse, but I'm nearly positive that it has an option where you can specify additional libraries. Yes, you'll have to do that once per project, but that shouldn't be a major overhead.
Try adding curl path in
Properties -> C/C++ General -> Paths and Symbols:
This is just how linking works in C and C++.
When you compile the program, you include the header file /usr/include/curl/curl.h. The compiler does this part. The header file contains all of the definitions for the library interface.
When you link the program, you link in the library /usr/lib/libcurl.so, or whatever it happens to be named. The linker does this part. The library contains the implementation in either a loadable (for dynamic libraries) or linkable (for static libraries) format.
The C and C++ languages have no way of specifying which libraries should be linked in, so you have to pass -lcurl to the linker. This is just the way it is.
There are some extensions to C and C++ that allow you to encode library dependencies in your source code, e.g., #pragma comment with MSC, but they're not supported by your typical ELF toolchain, as far as I know.
Note: Actually, the -lcurl flag is not for g++, but it is for the linker, ld. When you pass -lcurl to g++, g++ passes it through to the linker.
I'm writing a software that depends on the Poco c++ library. I can manage to compile the library on both Ubuntu and Windows, but only as static. That's fine since I want to use it statically. However, when I try to compile the program that depends on the libraries, I get an error similar to this (freely translated) :
Poco/RegularExpression.h: No such file or directory.
However, when I also explicitly tells the compiler where to look for the library's header files with the -I switch I get the following error instead (but maybe 20-30 similar lines) :
Undefined reference to (pthread_mutex...)
I've tried with a lot of different combinations, both directly with g++, and by using makefiles.
Am I supposed to include the paths to the libraries' header files, or have I somehow not succeeded to compile the libraries properly?
If I should include the paths, how can I get rid of the "undefined reference" error?
I'm pretty new with c++ programming so bear with me.
Thanks, Robert
This is very common error, I, too, suffer from it every now and then.
Did you include the .a to your project?
How do you include the headers? with <> or ""?
If the latter, make sure the files are in your include folder.
If first, make sure you have added the path to the files, or that they reside in g++'s global include folder
Is the library meant to be compiled as .so/.dll?
Normally if the library is meant to be dynamic, the static library only points to it.
Do you have included the dependencies the Poco itself requires? Like the -lpthread I think you are missing.
Try the -I option. In the target that has RegularExpression.h as a dependancy, try to include the directory that contains the above header file like so:
g++ -I/home/.../Poco <other options>
I'm fairly new to C++ (a long time Lisp programmer) and am trying to compile some of the examples for dlib on Windows using MinGW. I added dlib into the PATH. I then call g++ timer_ex.cpp from the examples directory. But I get a lot of error messages.
Short of using Visual Studio, what's the best way of compiling dlib examples on Windows?
Adding the folder to PATH usually doesn't work out well for me. Instead, try this command. I just compiled the example with it without error:
g++ timer_ex.cpp ..\dlib\all\source.cpp -I.. -luser32 -lws2_32 -lgdi32 -lcomctl32 -limm32
The somewhat cryptic -I.. adds the folder one level up to the include search path. This is the right thing to do assuming your haven't changed the folder layout. But in general this is the easiest way to add something to the compiler's include search path.
You also probably want to add the -O3 option which will tell gcc to produce optimized executables. Generally this makes the resulting application a lot faster, especially if you are doing heavy numerical work.
As an aside, you should consider installing CMake. It's a convenient tool which sets up a project like this for you. It works on Windows, Linux, Mac OS and many other platforms. To use it to compile the dlib example programs you would just have to say cmake . from within the example folder and then make. There is also a free version of visual studio which is quite nice, and as a bonus cmake can automatically create the project files for you.