I've recently moved over to CodeLite for C development, and i've been trying to get sigil to work for MinGW32.
I've been trying to include it locally from the project settings using the path F:/sigil-mingw32, where the library is located.
I have the parameter "Compiler/ Include Paths" set to F:/sigil-mingw32/include
And my linker path in "Linker/ Libraries Search Path" set to F:/sigil-mingw32/lib respectively.
I've set my "Linker/ Libraries" to include the library "libsigil.dll.a", But when i build my project i get the output:
c:/Program Files (x86)/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -l-libsigil.dll
And then the build fails.
Why is the linker excluding the .a suffix from the library dll file?
Turns out that CodeLite can directly link imported libraries without having to add the full path into your linker settings. Unlike in CodeBlocks, the linker will not remove the "lib" prefix in dll.a libraries when given a direct path to the library file.
So instead of "path/lib/libsigil.dll.a" Only the location of the library folder is provided in Linker/Libraries Search Path and the Libraries parameter will be passed to gcc directly, which excludes the "lib" prefix.
So setting the parameter as "sigil" instead of "libsigil.dll.a" is enough.
Related
I'm using windows and my goal is to add the glew library (http://glew.sourceforge.net/index.html) to mingw. I have downloaded mingw-w64 via GitHub (https://github.com/mstorsjo/llvm-mingw/releases/tag/20210423). It comes with a "bin", "lib" and "include" folder. Within the "bin" folder I do "make" to execute my project's makefile which inlcudes the line
LDLIBS=-lm -lGL -lGLEW -lglfw
I have copied "glew32.lib" to "mingw/lib", "GL/glew.h" and "GL/wglew.h" to "mingw/include/GL" and "bin/glew32.dll" to "mingw/bin".
In my source code i have included the header file with
#include <GL/glew.h>
When i do "make" i get an error on that line:
GL/glew.h: No such file or directory
How do you add custom libraries like glew to mingw?
When using a library use the -I compiler flag to tell the compiler where to find the include files (in your case the path containing the GL folder) and the -L linker flag to tell the linker where to find the libraries.
To link with the library use the -l flag. The library itself is a a lib*.a file (or lib*.dll.a for shared libraries). For the -l flag the library is specified without prefix and suffix, so if your library is called libglew.a the flag will be -lglew.
It is also possible to specified the full path to the lib*.a file instead of -L and -l flags, and with MinGW, if you have the .dll file you can even try to specify the path of the .dll file and the linker will know what to do.
I am working to build a Code Composer Studio project using cmake, which is new to me. It builds successfully under Linux but I am struggling to get it to work under Windows. The cmake command executes without issue, but make fails during the very first C object at the very first #include with the error code
fatal error: could not open source file "stdbool.h" (no directories in search list)
I'm using the libraries included in CCS's compiler (c6000_7.4.15), and that whole folder is included in the CSS project. I include it in cmake as well. In my .cmake file:
set (CCS_ROOT ${CCS_ROOT_V6_WIN} CACHE PATH "code composer install directory")
set(CGT_COMPILER_ROOT ${CCS_ROOT}/tools/compiler/c6000_7.4.15 CACHE INTERNAL "DSP Compiler Root")`
And in the CMakeLists.txt file:
set (COMPILER_INCLUDE ${CGT_COMPILER_ROOT}/include)
INCLUDE_DIRECTORIES ("${COMPILER_INCLUDE}")
Why can the header files not be opened when they're linked in the project and CMake can find them just fine?
EDIT: The directory structure had been changed underneath me, so I took the opportunity to add all of the external files directly into the project to make it completely platform-independent. That way, since the project is managed by our Git repository, users won't have to install the CSL or any other programs to build the project. This also means that paths to libraries and header files will never change between revisions and environments.
Unfortunately, this has not solved my problem. The project continues to build in Linux while failing to ind the very first included header file. I also notice that, under Windows, it cannot find my own header files unless I provide a relative path, e.g. #include "../Common.h" I can get make to find stdbool.h if I provide an absolute path to the compiler directory, but that exposes a web of additional broken links between files.
As a side note, the project builds successfully within Code Composer Studio, so I am assuming that this isn't an issue with my specific Windows environment nor with the code within the project itself.
This seems to be an issue with gcc.exe. I set an environment variable CC to the path of a different compiler (in my case a TI compiler) within my build script and that fixed the problem.
I'm working on packaging a library which has a bunch of header files, and a .a static library.
The C headers for the library are all in the root folder of the library, but the headers use some external typedefs held in a common/ directory.
I tried copying all the .h files into a directory /usr/include/libcapriltags, and all the common/*.h files into /usr/include/libcapriltags/common.
Then I symlinked the main .h file from /usr/include/libcapriltags/apriltag.h to /usr/include/apriltag.h
I also put the .a file in /usr/lib.
I could link against the library, but when I imported apriltag.h, gcc couldn't find anything in /usr/include/libcapriltags/common.
What am I doing wrong installing the library?
Supposing that the "library" headers reference the shared internal headers via the form ...
#include "common/my_typedefs.h"
..., it is incorrect to both install those headers in /usr/include/libcapriltags/common and at the same time symlink /usr/include/libcapriltags/apriltag.h to /usr/include/apriltag.h. The symlink will also be an issue if apriltag.h refers to other headers directly in /usr/include/libcapriltags/ via double-quote syntax.
When the compiler locates /usr/include/apriltag.h, it is unlikely to know or care whether that's a symlink. Any relative lookup it performs for other headers #included by apriltag.h will be relative to the path at which it found apriltag.h (the symlink).
On the other hand, if any of these headers refer to each other via the angle-bracket include syntax, then the root issue is that the directory in which you've installed them is not in the (default) include search path. Your symlink does nothing to address that, except with respect to its specific target file.
Supposing that you do want to put all the headers in and under /usr/include/libcapriltags, which is perfectly reasonable, you should be prepared to add that directory to the include file search path when you compile code that uses them. The traditional compiler option for doing so is spelled -I/usr/include/libcapriltags. Depending on how they're written, you might be also able to reference them via qualified form (#include <libcapriltags/apriltags.h>). Either way, you neither need nor want to symlink any files from that directory into /usr/include.
I have done the following:
Create new c project (Makefile Project with Existing Code)
Added a build variable that my Makefile complained about
Now my source .c file complains about #include files because it does not know where the lib folder is,I tried adding lib folder to library path (DID NOT WORK).
How can I link my project to an external lib folder so that my .c source file can read the .h files needed for the #include?
I added the library path to Paths and Symbols->Includes BUT when I go back to the project it only shows the root folder and nothing inside it. Do I also have to add each individual .so lib file?
Answered here : How do you add libraries to Eclipse CDT? (No such file or directory)
#cyfur01 has the best answer :
What to add depends on what you are trying to include. In the case of
Boost, there are a number of header-only libraries, and there are some
libraries that require linking in static/shared-object libraries
(e.g., serialization). Header-Only Libraries
For header-only libraries, you just need to include the base directory
of all the header files. With gcc, you add the directory using the -I
flag (e.g., -I C:/path/to/boost_52_0). With a managed makefile project
in Eclipse, you can accomplish the same using Properties > C/C++ Build
Settings > Tool Settings > GCC C++ Compiler > Directories Static/Shared-Object Libraries
For static/shared-object libraries, you have to specify two options:
-l --> The name of the library, less the 'lib' prefix and the file suffix (e.g., libboost_serialization.dll -> boost_serialization
-L --> The directory to look for the library file in. This is only needed if the library is on a non-standard path.
As #Chris pointed out, for a managed makefile project, both of these
options can be set through Properties > C/C++ Build > Settings > Tool
Settings > GCC C++ Linker > Libraries
ok so I figured it out:
(1) At the start I had a source.c and a MAKEFILE
(2) Create new c project (Makefile Project with Existing Code)
(3) MAKEFILE complained about a variable so I added it to environment variable
(4) #include files complained so I added external library like so
(a) I located my library path and found that there is a folder before /lib called include
(b) The include folder had a list of header files
(c) So I added the path to the include folder NOT the lib folder under paths and symbols include
WORKED LIKE A CHARM!
I'm sure this question has been asked many times, but I can't figure this out. Bear with me.
So when you download a library, you get a bunch of .c and .h files, plus a lot of other stuff. Now say you want to write a program using this library.
I copy all the .h files into my project directory. It just doesn't compile.
Great, so then I get the library as a bunch of .dll's, and i copy the dlls into my project directory. Still doesn't compile.
How does this work?
What do you do, like right after creating the folder for your project? What parts of the library package do you copy/paste into the folder? How do you make it so that it can compile? Go through the steps with me please.
Where to put the .h files?
Where to put the .dll files?
How to compile?
Thanks.
(the library I'm trying to get working is libpng, I'm in windows with MinGW, and i'm looking to compile from command-line like usual.)
(from what i gather, you put the .h files in directory A and the .dll files in directory B and you can use -l and -L compiler options to tell the compiler where to find them, is this correct?)
Here's a brief guide to what happens when you compile and build a basic C project:
The first stage compiles all your source files - this takes the source files you've written and translates them into what are called object files. At this stage the compiler needs to know the declaration of all functions you use in your code, even in external libraries, so you need to use #include to include the header files of whatever libraries you use. This also means that you need to tell the compiler the location of those header files. With GCC you can use the -I command line to feed in directories to be searched for header files.
The next stage is to link all the object files together into one executable. At this stage the linker needs to resolve the calls to external libraries. This means you need the library in object form. Most libraries will give you instructions on how to generate this or might supply it ready built. Under Linux the library file is often a .a or .so file, though it might just be a .o. Again you can feed the location of the library's object file to GCC with the -L option.
Thus your command line would look like this:
gcc myProg.c -I/path/to/libpng/include -L/path/to/libpng/lib -lpng -o myProg.exe
(Note that when using the -l command line GCC automatically adds lib to the start of the library, so -lpng causes libpng.a to be linked in.)
Hope that helps.
Doing it under windows (supposing you user Visual Studio)
After unpacking add the library include directories to your projects' settings (Project -> Properties -> C/C++ -> Additional Include Directories)
Do the same thing for the Libraries Directory (Project -> Properties -> Linker -> Additional Library Directories)
Specify the name of the library in your Linker Input: Project -> Properties -> Linker -> Input -> Additional Dependencies
After this hopefully should compile.
I don't recommend adding the directories above to the Global settings in Visual Studio (Tools -> Options -> Project and Solutions) since it will create and environment where something compiles on your computer and does NOT compile on another one.
Now, the hard way, doing it for a Makefile based build system:
Unpack your stuff
Specify the include directory under the -I g++ flag
Specify the Library directory under the -L g++ flag
Specify the libraries to use like: -llibrary name (for example: -lxml2 for libxml2.so)
Specify the static libraries like: library name.a
at the end you should have a command which is ugly and looks like:
g++ -I/work/my_library/include -L/work/my_library/lib -lmylib my_static.a -o appname_exe MYFILE.CPP
(the line above is not really tested just a general idea)
I recommend go, grab a template makefile from somewhere and add in all your stuff.
You must link against a .lib or something equivalent i.e. add the ".lib" to the libraries read by the linker. At least that's how it works under Linux... haven't done Windows so a long while.
The ".lib" contains symbols to data/functions inside the .dll shared library.
It depends on the library. For examples, some libraries contain precompiled binaries (e.g. dlls) and others you need to compile them yourself. You'd better see the library's documentation.
Basically, to compile you should:
(1) have the library's include (.h) file location in the compiler's include path,
(2) have the library stubs (.lib) location in the linker's library path, and have the linker reference the relevant library file.
In order to run the program you need to have the shared libraries (dlls) where the loader can see them, for example in your system32 directory.
There are two kinds of libraries: static and dynamic (or shared.)
Static libraries come in an object format and you link them directly into your application.
Shared or dynamic libraries reside in a seperate file (.dll or .so) which must be present at the time your application is run. They also come with object files you must link against your application, but in this case they contain nothing more than stubs that find and call the runtime binary (the .dll or the .so).
In either case, you must have some header files containing the signatures (declarations) of the library functions, else your code won't compile.
Some 'libraries' are header-only and you need do nothing more than include them. Some consist of header and source files. In that case you should compile and link the sources against your application just as you would do with a source file you wrote.
When you compile, assuming you have the libs and the headers in the same folder as the sources you are compiling, you need to add to your compile line -L . -I . -lpng. -L tells the linker where to look for the library, -I tells the compiler where to look for the headers and -lpng tells the linker to link with the png library.
[Edit]
Normal projects would have some sort of hierarchy where the headers are in an /include folder and the 3rd party libs are in a /libs folder. In this case, you'd put -I ./include and -L ./libs instead of -I . and -L.
[Edit2] Most projects make use of makefile in order to compile from the command line. You can only compile manually for a small number of files, it gets quite hectic after that
Also,
you may want to look over Dynamic Loading support in various languages and on various
platforms.
This support is very handy in cases when you want to use a library optionally and you don't want your program to fail in case that library is not available.