Adding external library
Hello everyone,
I want to add an external library into my c++ program(I use Dev c++ IDE).I have both the header and source file for the library. Where should I copy and paste it so that program uses it after I used #include "file_name.h" in my program because curently when i include it and run program it says NO SUCH FILE OR DIRECTORY EXISTS.
I want to add an external library into my c++ program(I use Dev c++ IDE).I have both the header and source file for the library. Where should I copy and paste it so that program uses it after I used #include "file_name.h" in my program because curently when i include it and run program it says NO SUCH FILE OR DIRECTORY EXISTS.
read a tutorial for the specific library, youtube or a wiki, a tutorial on the library website, a topic on stackoverflow, or an article.
in general even if there are no results for your specific case, you first need to know if the library works with your compiler, and if the library is NOT a headers only library, you also may need to compile the library for your specific compiler using a build system like Cmake or ninja or makefile or one of the many other build systems the library may offer. If you are very lucky you could have prebuilt binaries for the a very specific compiler version, but C++ isn't nearly as easily to link to a prebuilt binary as a prebuilt C library (if it is a C library congrats, it is very easy to link to a premade binary! usually), and being able to compile libraries from source will prepare you for writing cross platform code in the future, easily change compilers at need, and will give you a better understanding of how the C++ compiler works, which can help if you ever get into a real tricky build problem in the future.
In general for linking a project in a GCC comand line format (and probably similarish to how VS does it I imagine, but don't take my word for it) there are 3 parts:
1: include directories.
2: linker directories.
3: linker flags (or if you want to skip part 2, you can manually link directly to the linker file, but should be avoided when possible). These are flags with a
something to note is that this system makes dynamic libraries (DLL's) and static libraries (no DLL's) transparent, and it just depends on how the library was compiled on whether you need a DLL or not.
there is also an extra way of using libraries, which is the naive way (I wouldn't call it a library I would just call it a piece of code). which is to just include the headers and cpp files directly into your project that you are using.
You also aren't gonna get any help from us with such little effort put in your question.
If you still have problems give us every single thread of information you can, and give us your compile commands, your compiler version, open your project in CMD and tell us what the "tree" command tells us, where the library is located, where you downloaded the library, write a demo that only uses 2 files which pretty much does hello world, and try to reproduce the problem and if it worked, then start adding things into it piece by piece until it stops working. You should try to solve the problem yourself before you get to us.
I would also argue that my experience with mingw wasn't without suffering, I had fun with the difficulty, but if you want something easier to work with, Visual Studios just looks easier, because in many cases where you are dealt with "your only option is Cmake and something else you never heard of", you could search github and you will find someone who generated the solution files for VS and the specific version for you (and of course, pre-built binaries), but for mingw you aren't that lucky, or plain out "this code is cross platform, buuuuuuuuut for windows we use VS and nothing else, because mingw is not an industry standard and its extra maintenance". But I don't blame them since it is true that mingw has trivial flaws like with debugging core dumps, and the lack of the windows C runtime debug library (AKA memleaks and undefined behavior on windows), which are deal breakers.
in general even if there are no results for your specific case, you first need to know if the library works with your compiler, and if the library is NOT a headers only library, you also may need to compile the library for your specific compiler using a build system like Cmake or ninja or makefile or one of the many other build systems the library may offer. If you are very lucky you could have prebuilt binaries for the a very specific compiler version, but C++ isn't nearly as easily to link to a prebuilt binary as a prebuilt C library (if it is a C library congrats, it is very easy to link to a premade binary! usually), and being able to compile libraries from source will prepare you for writing cross platform code in the future, easily change compilers at need, and will give you a better understanding of how the C++ compiler works, which can help if you ever get into a real tricky build problem in the future.
In general for linking a project in a GCC comand line format (and probably similarish to how VS does it I imagine, but don't take my word for it) there are 3 parts:
1: include directories.
-I in the compile step, after the -O, usually libraries will just have a folder called "include" (not always), it contains header files, this is all you need for header only libraries. This allows you to use libraries with #include <library.h> , but note there is no difference between "" and <> other than common use of signifying if a header is a library or not.2: linker directories.
-L when you call the linking step, in the command line this step requires you to compile a project using more than 1 raw command which is the last step called linking, this folder is usually called "lib" or "lib/x64|x86", (also note that there are no rules, sometimes small libraries put the linker files and the binary DLL into the same folder which is called "win64/32", "obj", "bin" or something), this doesn't do anything without the 3rd and last step for specifically linker flags, similar how include directories don't do anything unless you #include the header. 3: linker flags (or if you want to skip part 2, you can manually link directly to the linker file, but should be avoided when possible). These are flags with a
-l in the linker step. These flags are connected to the names of .a for GCC or .lib for VS/clang, but the file extension is cut off, so "freetype.a" would be "-lfreetype".something to note is that this system makes dynamic libraries (DLL's) and static libraries (no DLL's) transparent, and it just depends on how the library was compiled on whether you need a DLL or not.
there is also an extra way of using libraries, which is the naive way (I wouldn't call it a library I would just call it a piece of code). which is to just include the headers and cpp files directly into your project that you are using.
You also aren't gonna get any help from us with such little effort put in your question.
If you still have problems give us every single thread of information you can, and give us your compile commands, your compiler version, open your project in CMD and tell us what the "tree" command tells us, where the library is located, where you downloaded the library, write a demo that only uses 2 files which pretty much does hello world, and try to reproduce the problem and if it worked, then start adding things into it piece by piece until it stops working. You should try to solve the problem yourself before you get to us.
I would also argue that my experience with mingw wasn't without suffering, I had fun with the difficulty, but if you want something easier to work with, Visual Studios just looks easier, because in many cases where you are dealt with "your only option is Cmake and something else you never heard of", you could search github and you will find someone who generated the solution files for VS and the specific version for you (and of course, pre-built binaries), but for mingw you aren't that lucky, or plain out "this code is cross platform, buuuuuuuuut for windows we use VS and nothing else, because mingw is not an industry standard and its extra maintenance". But I don't blame them since it is true that mingw has trivial flaws like with debugging core dumps, and the lack of the windows C runtime debug library (AKA memleaks and undefined behavior on windows), which are deal breakers.
Last edited on
Topic archived. No new replies allowed.