I recently made a small library in C, and I wanted to put it together with the standard libraries so I don't have to always copy the files for each new project.
Where do I have to put it so I can import it like the standard libraries?
Compiler : MinGW
OS: Windows
You need to create a library, but you don't necessarily need to put it in the same place as MinGW's standard libraries (in fact I think that's a bad idea).
It is better to put your own library/libraries in specific place and then use the -I compiler flag to tell the compiler where to find the header files (.h, .hpp, .hh) and the -L linker flag to tell the linker where to find the library archives (.a, .dll.a). If you have .dll files you should make sure they are in your PATH environment variable when you run your .exe or make sure the .dll files are copied in the same folder as your .exe.
If you use an IDE (e.g. Code::Blocks or Visual Studio Code) you can set these flags in the global IDE compiler/linker settings so you won't have to add the flags for each new project.
Then when building a project that uses your library you will need to add the -l flag with the library name to your linker flags, but without the lib prefix and without the extension (e.g. to use libmystuff.a/libmystuff.dll.a specify linker flag -lmystuff). The use of the -static flag will tell the linker to use the static library instead of the shared library if both are available.
I have created a minimal example library at https://github.com/brechtsanders/ci-test to illustrate on how to create a library that can be build both as static and shared (DLL) library on Windows, but the same code also compiles on
macOS and Linux.
If you don't use build tools like Make or CMake and want do the steps manually they would look like this for a static library:
gcc -c -o mystuff.o mystuff.c
ar cr libmystuff.a mystuff.c
To distribute the library in binary form you should distribute your header files (.h) and the library archive files (.a).
Im working on a program for my studies, that uses an open source library. It is meant to run on Raspberry Pi (Raspbian Kernel). Because of my intention to be also able to load it on a PLC i used mostly pure C. The Library itself comes with suitable header and .c files.
When i use the pre installed GCC compiler on the Raspberry my program compiles without any errors and works fine. Now here comes my problem:
I tried to get this projekt to work on windows using code::blocks IDE with MinGW installed. I revisited the library and downloaded the zip for windows (apperently same header and .c file, but also .lib and .dll included).
I set the search directories and linker settings within the project and included the header as usual with #include "header.h" for the relative path. It doesn't compile and gives alot multible definition and first defined here which usually indicate wrong linking and inclusion.
As i tried to identify some of this definitions i noticed that the functions which cause errors are defined one time in the library.c file. At the beginning of this .c file it also includes the header one time.
Short summary:
This works with raspbian GCC:
$ gcc -sdt=c99 main.c library.c -o executable
but gives errors with Windows IDE + MinGW
Am i missing something serious? The dynamic link lib should only be used by the executable afterwards. I thought maybe the libraby.c gets replaced by the library.lib but if i remove one of them the project doesn't know the functions. I also searched for wrong inclusions. I'm really at the end of my knowledge here, and also searched for posts that would help me, but those were mostly "where is the linker path" or "inclusion of .c files". It seems so an simple problem which i overlooked.
Any help Would be appriciated. I will supply more details if needed.
Thanks!
Edit (2):
obj\Debug\open62541.o:open62541.c:(.text+0x3152a): undefined reference to `__imp_shutdown'
obj\Debug\open62541.o:open62541.c:(.text+0x3153f): undefined reference to `__imp_closesocket'
obj\Debug\open62541.o:open62541.c:(.text+0x315a7): undefined reference to `__imp_send'
obj\Debug\open62541.o:open62541.c:(.text+0x315b9): undefined reference to `__imp_WSAGetLastError'
.....
Edit (3)
Answer 1!
Compiled good now, thanks everyone.
It looks like your library is open62541.
There are two ways to include the library in your source:
Build a shared/static lib and link it to your code
Enable Amalgamation which generates a single .c and .h file which you can directly compile with your code
You are combining both methods on mingw which adds the whole library two times.
Probably you only want to link the .c file without the .lib, thus your compile command should look something like this:
gcc -sdt=c99 main.c open62541.c -o test
Additionally, since open62541 needs the ws2_32 library on windows, the compiler should be called with:
gcc -std=c99 main.c open62541.c -o test -lws2_32
I am fairly new to C and I am trying to include a external library without using any IDE, only text-editor and the minGW compiler on windows cmd. The library is libPNG in this case, I would really like to understand how the process work not only for this library.
If there is a better way (and easier) to do this, I would also like to know.
You have two parts to take care of:
compilation,
linking.
Compilation
In compilation, when you transform source files in object files, your compiler must know what are the functions provided by the external library.
You could declare each function you use or you can include the library header file(s) in your code:
#incude <library_file.h>
It's not enough, you will have to tell your compiler where it can find this file:
-I<path_to_lib_folder> with gcc
/I<path_to_lib_folder> with cl (the visual studio compiler)
Linking
In linking process, you put the object and library files together to construct an executable file.
You need to tell the linker
what files it must use and
where it can find the library file
You tell the linker what files to use with the -l options, for instance, -lfoo will tell it to search for the libfoo.so lib
Note: with cl you can tell specify which library to use directly in your source code with #pragma comment (lib, "libfoo.lib")
Add you specify where with:
-L<path_to_lib_folder> with gcc
/LIBPATH:<path_to_lib_folder> with link (the visual studio linker)
You can also use dynamic linking, but let's start with the first step.
I am using the Pelles C IDE and for certain projects have to tell the linker to include a certain library e.g. Ws2_32.lib. Currently I am developing a function I plant to reuse frequently throughout numerous projects, so I decided to make a header file for it. Is there a way to tell the linker to include a certain library from the header file ?
You have link the library, no other way.
If compiler is gcc in linux, you can link the lirary libtemp.so like
gcc youfile.c -ltemp
And before running the executable add the path of libtemp.so to LD_LIBRARY_PATH
In your IDE you can config the samething.
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.