For example, the description of /lib/ is that it contents shared library files for the system.
What exactly is a library? Are we talking about library files similarly to importing a library in C? What is contained in a library file and what are they used for?
What relation does it have to a .dll
A library is just a block of code, and sometimes data, that can be used by other programs. Objects in a static library get physically included in a program's code at linking time, and each program using them will have its own copy. Objects in a shared library will be accessed by a program at run time. A .dll is just Microsoft's word for a shared library, the equivalent on Linux would usually be .so.
A library is a collection of routines that can be called from different programs or libraries. Dynamic (shared) libraries can be loaded at runtime, so the library can be swapped without having to recompile the programs using it. /lib/ contains the libraries available on your operating system, but they don't have to be C libraries.
.dll is the Windows equivalent of shared libraries (.so).
Related
I'm currently trying to incorporate some libraries into a Windows C++ project. Now I used to assume that .lib files were used for static libraries and .dll were used for dynamic libraries. Feel free to correct this thought.
However, after trying to actually use libraries (whether that be static or dynamic), it seems like you are required for provide a .lib. So that makes me think that .libs are not associated with just static libraries, but also dynamic libraries.
So how exactly are .lib files structured? How can your project determine whether or not a .lib file is associated with a static library or dynamic library? I assume there must be some information encoded into the .lib file that states whether or not this .lib file actually contains compiled classes/functions, or if it doesn't (in the case of dyanmic library).
What is the difference between static library and relocatable object file? Or between dynamic library and shared object file.
And if it's not equal things, what have dynamic library, that allows to link with it, but shared object file doesn't?
A static library is basically just a collection of object files. It's typically just an ar archive of object files. Using ar, you can extract object files from the library, add different object files to it, etc.
Generally speaking, the difference between a dynamic library and a shared object file is the target -- Windows uses dynamic libraries, Linux uses shared objects. There is a little more difference than that, but not a whole lot.
Dynamic (shared) libraries uses PIC code - the code will work regardless of the actual physical location of the library that is used by multiple executables in memory.
Static libraries are linked into the executable during the linking phased to create the executable.
The advantage of dynamic libraries is the smaller footprint of the executable in memory. The advantage of static libraries is that you can just deliver the executable without the need to have the dynamic libraries and run a little faster and no effort is required to enable the library to exist anywhere in physical memory.
Shard libraries save disk space if they are used by more than one executable. If multiple executable's that use the same function from a shared lib. are running each will get its own copy. Neither executable on disk will include that function's code but rather a reference to the shared lib.
Lets say I have a massive project which consists of multiple dynamic libraries that will all get installed to /usr/lib or /usr/lib64. Now lets say that one of the libraries call into another of the compiled libraries. If I place both of the libraries that are dependent on eachother in the same location will the ld program be able to allow the two libraries to call eachother?
The answer is perhaps yes, but it is a very bad design to have circular references between two libraries (i.e. liba.so containing function fa, calling function fb from libb.so, calling function ga from liba.so).
You should merge the two libraries in one libbig.so. And don't worry, libraries can be quite big. (some corporations have Linux libraries of several hundred megabytes of code).
The gold linker from package binutils-gold on Debian should be useful to you. It works faster than the older linker from binutils.
Yes, as long as their location is present in set of directories ld searches for libraries in. You can override this set by using LD_LIBRARY_PATH enviroment variable.
See this manual, it will resolve your questions.
If you mean the runtime dynamic linker /lib/ld-linux* (as opposed to /usr/bin/ld), it will look for libraries in your LD_LIBRARY_PATH, which typically includes /usr/lib and /usr/lib64.
In general, /lib/ld-* are used for .so libraries at run-time; /usr/bin/ld is used for .a libraries at compile-time.
However, if your libraries are using dlopen() or similar to find one another (e.g. plug-ins), they may have other mechanisms for finding one another. For example, many plug-in systems will use dlopen to read every library in a certain (one or many) directory/ies.
I'm trying to install multiple packages into an initial ram file system. I'm using uclibc as my C library. This could be a stupid question but...
Would the compiled program also need a C library installed onto the initramfs?
Am I right in thinking that when a program is compiled from source, it is compiled into some sort of executable? Will the application on the initramfs be ready to run once I have make installed (with the correct prefix and providing dependencies are met )?
Whether a compiled program needs a C library - or any kind of library, for that matter - depends on how it was linked.
In general, if your program was linked statically then it does not have any external dependencies - it only needs a working kernel. The executable code of any library that it depends on will have been incorporated into the final executable.
If, on the other hand, it is linked dynamically, then it still needs the shared object files of the libraries it depends on. On Linux, most library shared objects (also known as shared libraries) follow the convention of having a filename with either a .so extension or, in general, a *.so.* format. For example /lib/libssl3.so and /lib/libncurses.so.5.9 are both shared libraries on my system.
It is also possible to have an executable that is statically linked against some libraries and dynamically linked against others. A common case where this happens is when rare or proprietary libraries are linked in statically, while standard system libraries are linked in dynamically.
I wish to know how the Shared library works I am asking in terms of Symbol table reference.
Is it like when we include a shared library it exports the Symbol table to process then based on some pointers we execute the respective function.
What is the meaning of Shared library Strip ?
Edit :- I wish to know that how shared library works when it get loaded into the memory.\
When a function lets say Fun() get called from the application which has def in library. then how this linking happen . I hope now its clear.
Programs make calls to a shared library through a Procedure Linkage Table, which is filled in by the dynamic linker/loader ld.so based on the information in the dynamic symbol table and relocation entries. On Linux this data is stored in programs and libraries in the ELF format, which you can inspect using programs like objdump and readelf.
This Linux Journal article has a basic overview. For more detailed information check out Ulrich Drepper's excellent paper How To Write Shared Libraries, and the Solaris Linker and Libraries Guide.