Suppose I have some code written in C with some data structures defined and some functions to work with those structures and all that is in a directory called src1. Suppose now I want to distribute this code.
If I want to use the external code in src1 in a project what should I do? Should I compile the code in src1 to an .a archive and then include that archive in the other projects I want to use?
Basically what I need to know is the correct conventions to use external code in a project.
Thanks in advance.
To distribute the code in the form of libraries you need follow the below steps:
List down the set of structure, functions, macros etc which you want to expose to other projects.
Group the set of data listed in Point-1 into a set of header files. Rest of your internal stuff can be in other header files.
Compile your code into a static(It will .a for linux based systems or .lib for windows) or dynamic library (It will be a .so/.sl for linux based systems or .dll for windows)
Provide your library and the set of exposed header files (as decided in point-2 above) to the other projects.
Link for creating static or shared libraries using gcc is here
Link for creating static or dynamic libraries in Windows using MSVC is here
Yes, you can use a static library, which is an .a file in Linux, and typically a .lib in Windows. This also requires that you share the header of course, so the code that uses the library can have the proper data structure definitions.
You can use any format (.a or .so) to distribute your library. The first one is static ally Inked and the second one is dynamically linked. To know more see this answer Difference between static and shared libraries?
Which ever you use you always link it in the same way.
gcc -L/path/to/lib -lsrc1 source.c -o source.o
Here, /path/to/lib can contain any of your previously compiled libsrc1.so or libsrc1.a
Related
I'm currently working on an old program written in C that consists of a shared library and some utilities. The library is built by first building every subproject as a static c library and then linking those together in a shared library.
The layout of the project is very similar to the project in this question.
Previously I built my C programs by linking every object build together. What is the benefit of using static archives instead of object files in this case?
What is the benefit of using static archives instead of object files in this case?
There is no particular benefit, but building multiple archive libraries which are later linked into a single binary or shared library can make Makefiles easier to write. However, see "Recursive Make Considered Harmful".
The background is following: there is 3'rd party provider that provides us with a libveryfancylib.so, in 32b. Softaware that uses the library has quite a load of other linux library dependencies (like QT) also, but they are open source, so no problem for statical linking. The target platform is 64b and running Debian 7.
We can ship the program with binary + dynamical libraries, no problem, but i would rather see single static binary with no dependencies.
So my question is: why i cannot link the dynamical library into static binary? I mean what bit of information is there missing, or is it just feature that is rarely needed -> not implemented.
We can ship the program with binary + dynamical libraries, no problem, but i would rather see single static binary with no dependencies.
What is the problem you are trying to solve?
You can follow the model most commercial applications on Linux do: put your executable, shared libraries and other resources in one directory (possibly with subdirectories). When linking your executable against those shared libraries pass -Wl,-rpath,'$ORIGIN' (in make use -Wl,-rpath,'$$ORIGIN') to the linker, so that when starting your application the runtime linker looks for required shared libraries in the same directory where executable is.
Then archive that directory and give it to your users.
There are programs for MS Windows that can do so, eg DLL to Lib and DLL to Static Lib.
In the open source world, there isn't really much of an incentive to develop such a tool as you can always recompile from source (but of course it's possible that someone somewhere did it anyway).
It's because dynamic libraries and static libraries are two different things. A static library is just an archive of object files (much like a zip archive). A dynamic library is more like an executable program.
So you can't really link anything into a static library, you can only add more object files.
How can I convert a pre-built dynamic executable to a static one without recompiling from source? I am using ARMv7 cpu on Linux and I have acess to libraries which are needed by the dynamic executable one . ( I can not use Ermine or Statifier !)
You need the static versions of the libraries you are using, and link them to a compiled version of your program that is prepared for static linking.
So I don't think you can circumvent recompiling.
If you have all the .o files, then you can simply link them with the static versions of the libraries.
This means it's possible to create a static version without compiling from source but usually, people don't keep the .o files so I guess you will have to compile everything from source.
I've encountered a few cases building projects which use shared libraries or dynamic-loaded modules where the module/library depends on another library, but doesn't check that a shared copy is available before trying to link. This causes object files from a static archive (.a file) to get pulled into the resulting .so, and since these object files are non-PIC, the resulting .so file either has TEXTRELs (very bad load performance and memory usage) or fails altogether (on archs like x86_64 that don't support non-PIC shared libraries).
Is there any way I can make the gcc compiler driver refuse to link static library code into shared library output? It seems difficult and complicated by the possible need to link minimal amounts from libgcc.a and the like...
As you know, you can use -static to only link against static libraries, but there doesn't appear to be a good equivalent to only linking against dynamic libraries.
The following answer may be useful...
How to link using GCC without -l nor hardcoding path for a library that does not follow the libNAME.so naming convention?
You can use -l:[libraryname].so to list the dynamic libraries you want to link against in your library search path. Specifying the .so ending will probably help with your dynamic library only case. You will probably have to specify the whole name with the 'lib' prefix instead of just the shortened version.
please, could someone explain to me a few basic things about working with languages like C? Especially on Windows?
If I want to use some other library, what do I need from the library? Header files .h and ..?
What is the difference between .dll and .dll.a.? .dll and .lib? .dll and .exe? What is .def?
Does it matter how was the library compiled? I mean, is it possible to use, on Windows, a C++ library compiled by VC from within my C code compiled by MinGW?
To use another library, what is preferred way? LoadLibrary() or #include <>?
There are some libraries which only provide the source code or .dll - how to use such libraries? Do I have to recompile them every time I rebuild my project?
How do I create one big .exe? Is this called "static linking"?
How to include some random file into .exe? Say a program icon or start-up song?
How do I split my huge .c into smaller ones? Do I need to create for every part a header file which then I include in the part with WinMain() or main()?
If there is a library which needs another library, is it possible to combine these two into one file? Say, python26.dll needs msvcr90.dll and Microsoft.VC90.CRT.manifest
What happens if I don't free previously allocated memory? Is this going to be cleaned up if the program (process) dies?
Well, so many question... Thanks for every info!
1: If I want to use some other library, what do I need from the library? Header files .h and ..?
... and, usually a *.lib file which you pass as an argument to your linker.
2: What is the difference between .dll and .dll.a.? .dll and .lib? .dll and .exe? What is .def?
This might be useful: Static libraries, dynamic libraries, DLLs, entry points, headers … how to get out of this alive?
3: Does it matter how was the library compiled? I mean, is it possible to use, on Windows, a C++ library compiled by VC from within my C code compiled by MinGW?
Yes, it matters. For interop between compilers, the normal way is to use a C-style (not C++-style) API, with well-defined parameter-passing conventions (e.g. __stdcall), or to use 'COM' interfaces.
4: To use another library, what is preferred way? LoadLibrary() or #include <>?
#include is for the compiler (e.g. so that it can compile calls to the library); and LoadLibrary (or, using a *.lib file) is for the run-time linker/loader (so that it can substitute the actual address of those library methods into your code): i.e. you need both.
5: There are some libraries which only provide the source code or .dll - how to use such libraries? Do I have to recompile them every time I rebuild my project?
If it's only source then you can compile that source (once) into a library, and then (when you build your project) link to that library (without recompiling the library).
6: How do I create one big .exe? Is this called "static linking"?
Yes, compile everything and pass it all to the linker.
7: How to include some random file into .exe? Say a program icon or start-up song?
Define that in a Windows-specific 'resource file', which is compiled by the 'resource compiler'.
8: How do I split my huge .c into smaller ones? Do I need to create for every part a header file which then I include in the part with WinMain() or main()?
Yes.
9: If there is a library which needs another library, is it possible to combine these two into one file? Say, python26.dll needs msvcr90.dll and Microsoft.VC90.CRT.manifest
I don't understand your question/example.
10: What happens if I don't free previously allocated memory? Is this going to be cleaned up if the program (process) dies?
Yes.
If I want to use some other library, what do I need from the library? Header files .h and ..?
You need header .h or .hpp for C,C++ although some languages don't require header files. You'll also need .a, .so, .dll, .lib, .jar etc files. These files contain the machine code that you linker can link into your program. Goes without saying that the format of library is must be understood by you linker.
What is the difference between .dll and .dll.a.? .dll and .lib? .dll and .exe? What is .def?
dll and .a are library files, that contain code components that you can link into your own program. a .exe is your final program into which .a or .dll has already been linked.
Does it matter how was the library compiled? I mean, is it possible to use, on Windows, a C++ library compiled by VC from within my C code compiled by MinGW?
Yes, it is important that the library that you are using is compatible with your platform. Typically Unix libraries will not run on windows and vice versa, if you are using JAVA you are better off since a .jar files will usually work on any platform with JAVA enabled (though versions matter )
To use another library, what is preferred way? LoadLibrary() or #include <>?
include is not a way to use a library its just a preprocessor directive telling you preprocessor to include a external source file in your current source file. This file can be any file not just .h although usually it would be .h or a .hpp
You'll be better off my leaving the decision about when to load a library to you runtime environment or your linker, unless you know for sure that loading a library at a particular point of time is going to add some value to your code. The performance cost and exact method of doing this is platform dependent.
There are some libraries which only provide the source code or .dll - how to use such libraries? Do I have to recompile them every time I rebuild my project?
If you have source code you'll need to recompile it every time you make a change to it.
however if you have not changed the source of library in anyway there is no need to recompile it. The build tool like Make are intelligent enough to take this decision for you.
How do I create one big .exe? Is this called "static linking"?
Creating a static .exe is dependent on the build tool you are using.
with gcc this would usually mean that you have to you -static option
gcc -static -o my.exe my.c
How to include some random file into .exe? Say a program icon or start-up song?
Nothing in programming is random. If it were we would be in trouble. Again the way you can play a song or display an icon is dependent on the platform you are using on some platforms it may even be impossible to do so.
How do I split my huge .c into smaller ones? Do I need to create for every part a header file which then I include in the part with WinMain() or main()?
You'll need a header file with all your function prototypes and you can split you program into several .c files that contain one or more functions. You main files will include the header file. All source files need to be compiled individually and then linked into one executable. Typically you'll get a .o for every .c and then you link all the .o together to get a .exe
If there is a library which needs another library, is it possible to combine these two into one file? Say, python26.dll needs msvcr90.dll and Microsoft.VC90.CRT.manifest
Yes one library may require another library however its not advisable to package different libraries together, you may be violating the IPR and also for the fact that each library is usually a well define unit with a specific purpose and combining them into one usually doesn't make much sense.
What happens if I don't free previously allocated memory? Is this going to be cleaned up if the program (process) dies?
Again depends on the platform, usually on most OS the memory will be recovered after the program dies but on certain platforms like an embedded system it may be permanently lost.
It always a good idea to clean up the resources your program has used.
In all seriousness, the place to go to learn how to run your local environment is the documentation for your local environment. After all we on not even know exactly what your environment is, much less have it in front of us.
But here are some answers:
1. You need the headers, and a linkable object of some kind. Or you need the source so that you can build these.
3. It matters that the library is in a format that your linker understands. In c++ and perhaps other languages, it also needs to understand the name mangling that was used.
6. Forcing all the library code to be included in the executable is, indeed, called "static linking".
7. There is at least one StackOverflow question on "resource compilers".