best practices on my library coded in C - c

it is awkward, but until now i always copy the *.h and the *.c files to my projekts location. this is a mess and i want to change it!
i want to build my own c library and have a few questions about it.
where should i locate the *.h files?
should i copy them in the global /usr/include/ folder or should i create my own folder in $HOME (or anywhere else)?
where should i locate the *.a files and the *.o files and where the *.c files.
i am using debian and gcc. my c projects are in $HOME/dev/c/.
i would keep my lib-sources in $HOME/dev/c/lib (if this is the way you could recommend) and copy the *.o, *.a and *.h files to the location i am asking for.
how would you introduce the lib-location to the compiler? should i add it to the $PATH or should i introduce it in the makefiles of my projekt (like -L PATH/TO/LIBRARY -l LIBRARY).
do you have anny further tips and tricks for building a own library?

I would recommend putting the files somewhere in your $HOME directory. Let's say you've created a library called linluk and you want to keep that library under $HOME/dev/c/linluk. That would be your project root.
You'll want a sensible directory structure. My suggestion is to have a lib directory containing your library and an include directory with the header files.
$PROJECT_ROOT/
lib/
liblinluk.so
include/
linluk.h
src/
linluk.c
Makefile
Compiling: When you want to use this library in another project, you'd then add -I$PROJECT_ROOT/include to the compile line so that you could write #include <linluk.h> in the source files.
Linking: You would add -L$PROJECT_ROOT/lib -llinluk to the linker command line to pull in the compiled library at link time. Make sure your .so file has that lib prefix: it should be liblinluk.so, not linluk.so.
A src directory and Makefile are optional. The source code wouldn't be needed by users of the library, though it might be helpful to have it there in case someone wants to remake the .so file.

As I commented, you should try first to build and install from its source code several free software libraries, e.g. like libonion or gdbm or GNU readline etc (don't use any distribution package, but compile and install these from source code). This will teach you some good practice.
You probably want to install these libraries system-wide, not for your particular user. Then, assuming that your library is called foo (you need to give it some name!),
the header files *.h go into /usr/local/include/foo/
the shared objects (dynamic libraries) go into /usr/local/lib/libfoo.so (with perhaps some version numbering)
if relevant, static library go into /usr/local/lib/libfoo.a
You need to add once /usr/local/lib/ into /etc/ld.so.conf and run ldconfig(8)
and you usually don't want to copy any source file *.c or object file *.o
(except for homoiconic programs, bootstrapped compilers, Quine programs, generated C code, etc... See RefPerSys or Jacques Pitrat systems as an incomplete example of self generated C or C++). In some weird cases, you may want to copy such "source" or "generated C" code under /usr/src/.
Read Program Library HowTo (and later, Drepper's paper: How To Write Shared Libraries)
You could consider making your library known by pkg-config. Then install some foo.pc under /usr/local/lib/pkgconfig/
BTW, I strongly suggest you to publish your library as free software, perhaps on github or elsewhere. You'll get useful feedback and could get some help and some bug reports or enhancements.
You probably should use some builder like make and have an install target in your Makefile (hint: make it use the DESTDIR convention).

Related

How can I use my C library as others like stdio

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).

How to install C source files and headers?

I've been given these source files and headers. In the README.md the authors explain how to launch the test executables without the need of a proper installation. It is just a make command to run. They explain how to generate the .so files. I think these latter are meant to be used if I wanted to install the APIs at a system level (the definitions should be in api.h). My question is: where should I copy the shared objects generated by the Makefile and the api.h header? I aim to write a source file from scratch where I use those APIs (e.g. crypto_sign()) just including the headers, if it is possible. Thanks
where should I copy the shared objects generated by the Makefile and the api.h header? I aim to write a source file from scratch where I use those APIs (e.g. crypto_sign()) just including the headers, if it is possible
Nowhere.
The project comes with CMake support. Use CMake in your project and just add_subdirectory the repository directory.
Anyway, if you really wish to install the library system-wide, then FHS specifies directory structure on linux. For local system administration use /usr/local/lib for local libraries .so files and /usr/local/include for local C header files.

Do I really need to specify library location for linking with automake?

I am working on a multi-platform C program. The makefile has become pretty complicated because of all the different compilers, library locations, etc. on each machine. I figured Autoconf/Automake would be a good solution, though my previous experience using those tools was minimal.
My Makefile.am has the line LIBS=-lX11, but linking fails with the error "/usr/bin/ld: cannot find -lX11". I can work around this by adding "-L/usr/X11R6/lib/" to the definition of LIBS, but should I really need to do that? When I run ./configure, it says:
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
So it seems like Automake should know where to find it. Is there a way I can reference its location in Makefile.am without having to hardcode it, since the X11 libs will be in a different place on each machine?
Your Makefile.am should not set LIBS. If you need to link with a library, configure.ac should include a check for the library and the configure script will set LIBS accordingly. Also, Makefile.am should not specify paths to libraries. Each system should be configured so that the precompiler can find the headers and the linker can find the libraries. If the system is not set up so that the linker can find a library, the correct solution is for the user to specify the location in LDFLAGS rather than hard coding something in Makefile.am. (eg, rather than adding -L/p/a/t/h to a Makefile, you should add LDFLAGS=-L/p/a/t/h to the invocation of configure.)

How do I install C packages on windows

I have to use LU decompostion to fit a simple model to some data (simulated) in C. An example of what I need to do is here:
However, I'm stuck with a more basic problem: how do I install packages in C and call them in my code?
I'm new in C and I'm used to R. But I have this assingment to do some tests about Matrix inversion, LU decomposision and the professor suggested using Lapack to easy things (thus, I don't need to code myself the LU decomposition etc.). But I don't know how to install the package and call it in my code, in order to use the functions of LAPACK.
I have a windows 7 64 bits and I'm using compiler Code Blocks 8.02
Thanks for any help.
Normally you don't "install" C libraries in that sense. Normally, in Windows you have three types of files. The header files, typically ending in .h, the dynamic library, .dll, and most likely some linker files (typically, .lib, .a or something). The linker and compiler will need to be able to find these files somewhere. Normally you set the include directory paths, and library directory paths.
E.g. Let's say you downloaded a library called foo, and you extract it to C:\foo.
In that folder, libfoo.a, foo.dll and foo.h reside. In Code::Blocks you will have to point include directory path to C:\foo and library path to C:\foo so that the linker and compiler know where to look for these files. Since you're linking against the foo library, you will also have to set -lfoo or something similiar in linker command line. This is GCC syntax, but I think Code::Blocks uses GCC compiler behind the scenes anyways.
In the C code you can just #include <foo.h> and the compiler will find it for you.
You need to install that library and it might actually supply a tool for that. Check their documentation (e.g. a file INSTALL or README in their distributed sources). If the library uses only headers you might only need to copy it's headers to some directory on your system, but their buildsystem might be able to do that for you.
Once that is done you would tell your IDE on where to look for the sources and if the library uses not just headers to link against the actual library file. See the documentation in the Code::Blocks Wiki on how this is done for some example cases and adapt for your library.
The simplest thing to do in your situation is to install Cygwin. You can use the setup.exe installer to install the GCC and the LAPACK libraries. When you want to use the LAPACK library, you will add the -llapack option to your GCC command line.

How do you actually use a C library?

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.

Resources