I want to use some other project libraries in my implementation. The project has a /common folder where the libraries are located I want to include. In my makefile under LDLIBSOPTIONS, I included the path where /common folder is located like:
LDLIBSOPTIONS=-lpci -lpthread -I../../../OtherProj/Libs/common/
Then I include one .h file like:
#include <ExampleLib.h>
However I still get
fatal error: XXX.h: No such file or directory
What am I doing wrong? Thanks.
LDLIBSOPTIONS (more conventionally LDFLAGS) is used for specifying options to the linker. You need to specify the directory, using the -I flag, in CXXFLAGS:
CXXFLAGS += -I../../../OtherProj/Libs/common/
However given you are using non-standard names for your Makefile variables, CXXFLAGS might be called something like CXXOPTIONS, but the exact name is unknown to me.
Once this is solved you're going to be getting linker errors until you start specifying the library path using -L; perhaps:
LDLIBSOPTIONS = -L../../../OtherProj/Libs/common/ -lpci -lpthread
Related
I'm getting the error
c:\mingw\lib\gcc\mingw32\6.3.0\include\c++\cstdlib:75:25: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
when adding C:\MinGW\include to the compiler include search path:
echo "#include <cstdlib>" | g++ -x c++ - -isystem C:/MinGW/include -o /dev/nul
But CMake does this because some libraries (libcurl e.g.) are installed into C:\MinGW hence the curl include dir is C:\MinGW\include
Am I doing something wrong or is this a bug in MinGW?
I'm using MinGW 5.0.1.
What works: echo "#include <cstdlib>" | g++ -x c++ - -IC:/MinGW/include -o /dev/nul but I don't want to include the curl include dirs etc. as non-system includes.
Related to mingw/include/c++/cstdlib: stdlib.h: No such file or directory
Background: I'm using cmake to generate the makefiles. So there is a find_package(Curl) and a include_directories(SYSTEM CURL_INCLUDE_DIRS) in the CMakelists.txt. As libcurl is installed to C:/MinGW the CURL_INCLUDE_DIRS will be C:/MinGW/include and hence the -isystem include. I don't want to omit the SYSTEM because this might cause warnings to be generated for the libcurl headers. Of course there are more libraries that are also installed in the same way and I want to keep the cmake files portable.
The problem lies in the use of include_next of the C++ standard header. According to https://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html it will include the header searching the list of header file directories after the directory in which the current file was found. The standard include directories (using g++ -v) are (corrected):
c:\mingw\lib/gcc/mingw32/6.3.0/include/c++
c:\mingw\lib/gcc/mingw32/6.3.0/include/c++/mingw32
c:\mingw\lib/gcc/mingw32/6.3.0/include/c++/backward
c:\mingw\lib/gcc/mingw32/6.3.0/include
c:\mingw\include
c:\mingw\lib/gcc/mingw32/6.3.0/include-fixed
c:\mingw\mingw32/include
Hence the cstdlib will be found in c:\mingw\lib/gcc/mingw32/6.3.0/include/c++ and include_next "stdlib.h" will go further down this list and will find it in c:\mingw\include.
Now the problem: Installing the libraries into C:\mingw (using the lib, bin and include folders from the library) will make CMake correctly find them there and add the C:\mingw\include folder explicitly to the include list. The 2 cases work out as following:
Adding as -I: This will be ignored by g++ with ignoring ... as it is a non-system directory that duplicates a system directory
Adding as -isystem: This will prepend the directory to the list above and remove it from the rest as a duplicate (verified with the -v option). This means that when cstdlib is found and include_next is evaluated it will search only downward the list. But the directory containing the stdlib.h is not down the list anymore but upwards and therefore not searched. Hence the error.
Note: I found another definition of include_next which only discards the directory containing the header. That would work in this case but can lead to loops and was changed to the described behaviour.
Solution so far is simply installing or copying the libraries to C:\mingw\mingw32 instead.
I am currently trying to link a library using MinGW with the following command:
g++ main.cpp -l"C:\Users\Trent\Desktop\glfw3"
This command does not work, however the following does:
g++ main.cpp -lglfw3
Because of this, I think the compiler is probably searching for glfw3.dll in C:\Users\Trent\Desktop\C:\Users\Trent\Desktop which obviously doesn't exist. Is there a way to tell G++ to search for a library using an absolute path rather than a relative one?
P.S. The main.cpp file contains no code, I am simply just trying to link a DLL before I actually write anything.
For gcc family -l is option to specify library name, it searches names in system folders (defined in environment), you can add folders to lookup list by the -L option, just like VTT commented.
I just installed RtMidi for a project and compiled it. The examples in the tests folder work and so does my code if I put it in the folder and include it in the Makefile that compiles all the examples. How can I use RtMidi in a project with #include <RtMidi.h> instead of having my code in the tests folder? More specifically, what should I put in my Makefile? I've read a bit about dynamic and static libraries but I have no idea what I should be looking for. I've tried adding -llibrtmidi and /usr/local/lib/librtmidi.a without success.
In a standard Makefile, the CXXFLAGS macro defines flags for the C++ compiler. You will need to add -I<path to header directory> to this macro for the compiler to find the RtMidi header files.
Then you will need to add -L<path to lib directory> to the link step of the Makefile so that -lrtmidi will find the library file. (Note that you omit the lib prefix for the -l command)
Based on your description of your environment, you may require something like
CPPFLAGS += -I/usr/local/include
LDFLAGS += -L/usr/local/lib
LDLIBS += -lrtmidi
in your Makefile. make uses a lot of these implicit variables.
I am trying to execute a cpp file named "palindrome.cpp" using terminal on my Macbook. This cpp file uses an external library named "libStanfordCPPLib.a" which lies under "DIRECTORY TO CPP FILE/StanfordCPPLib", also the corresponding header files of this library are in this "StanfordCPPLib" folder.
You can see the folder structure by this screenshot:
My code for compiling this source code is :
g++-4.8 -Wall -I/Users/myName/Downloads/CS106B/palindrome/StanfordCPPLib -L/Users/myName/Downloads/CS106B/palindrome/StanfordCPPLib palindrome.cpp libStanfordCPPLib.a
As I understand, -I stands for the directory path where header files exist, and -L stands for the directory path where library (.a file) exists. That's why both -I and -L are the same directory path "/Users/myName/Downloads/CS106B/palindrome/StanfordCPPLib".
However, executing this command returns an error saying :"libStanfordCPPLib.a: No such file or directory". As is shown in the screenshot:
Can anyone see why this happens? Thanks.
Try this, using -lStanfordCPPLib:
g++-4.8 -Wall -I/Users/myName/Downloads/CS106B/palindrome/StanfordCPPLib -L/Users/myName/Downloads/CS106B/palindrome/StanfordCPPLib palindrome.cpp -lStanfordCPPLib
I am familiar with very simple g++ commands that compile and link programs, however when working with GTK+ I found the tutorial indicate that I should use pkg-config --cflags gtk+-2.0
Now when I type in pkg-config --cflags gtk+-2.0 to the terminal I get a list of libraries and files like this...
-pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/harfbuzz
So my question is, what does the -I mean in front of a directory? For example -I/usr/include/libpng12
The -I flag is used to add directories to the list of directories to search for finding files in #include <> statements.
In your case, when a file is included by using #include, /usr/include/libpng12 will be one of the directories in which the pre-processor will search for the file.
Please read the manual. All command line options are present there :-)
-I set the search path for libraries.
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
-I is simply adding to the paths to be searched for header files. Note that these are searched before system paths.
You can find pretty much all the options for gcc/g++ here. In this case, you want the Directory Search options specifically; see here. From that page:
-Idir
Add the directory dir to the head of the list of directories to be
searched for header files. This can be used to override a system
header file, substituting your own version, since these directories
are searched before the system header file directories. However, you
should not use this option to add directories that contain
vendor-supplied system header files (use -isystem for that).
If you use more than one -I option, the directories are scanned in
left-to-right order; the standard system directories come after. If a
standard system include directory, or a directory specified with
-isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal
position in the system include chain. This is to ensure that GCC's
procedure to fix buggy system headers and the ordering for the
include_next directive are not inadvertently changed. If you really
need to change the search order for system directories, use the
-nostdinc and/or -isystem options.
As the answers from #R Sahu #Klaus and #Yuushi explain, the -I dir tells the compiler where to look for the #include header.h file.
When the program is compiled, it will be linked. You will probably also need to tell the linker where to find the programs that support the functions in the #included headers. This is done with the -llibrary flag. That is a lower case l not a one (1).
The pkg-config command references a set of files and will supply the compiler flags --cflags and link flags --ldflags if you supply the package name.
Put the returned -Includes before the source name(s) and the -l's after in your compile command request.
For other than casual, one-off programs, you should use make. The cflag and ldflag info can be put in variables in the Makefile and referenced throughout your make script.
You can get a complete list of packages configured to pkg-config on your Ubuntu system with locate *.pc