Difference between shared objects so static libraries a and DLL s so

Question

I have been involved in some debate with respect to libraries in Linux  and would like to confirm some things  It is to my understanding  please correct me if I am wrong and I will edit my post later   that there are two ways of using libraries when building an application   Static libraries   a files   At link time  a copy of the entire library is put into the final application so that the functions within the library are always available to the calling application Shared objects   so files   At link time  the object is just verified against its API via the corresponding header   h  file  The library isn t actually used until runtime  where it is needed   The obvious advantage of static libraries is that they allow the entire application to be self-contained  while the benefit of dynamic libraries is that the  quot  so quot  file can be replaced  ie  in case it needs to be updated due to a security bug  without requiring the base application to be recompiled  I have heard some people make a distinction between shared objects and dynamic linked libraries  DLL s   even though they are both  quot  so quot  files  Is there any distinction between shared objects and DLLs when it comes to C C   development on Linux or any other POSIX compliant OS  ie  MINIX  UNIX  QNX  etc   I am told that one key difference  so far  is that shared objects are just used at runtime  while DLL s must be opened first using the dlopen   call within the application  Finally  I have also heard some developers mention  quot shared archives quot   which  to my understanding  are also static libraries themselves  but are never used by an application directly  Instead  other static libraries will link against the  quot shared archives quot  to pull some  but not all  functions resources from the shared archive into the static library being built  Thank you all in advance for your assistance  Update  In the context in which these terms were provided to me  it was effectively erroneous terms used by a team of Windows developers that had to learn Linux  I tried to correct them  but the  incorrect  language norms stuck   Shared Object  A library that is automatically linked into a program when the program starts  and exists as a standalone file  The library is included in the linking list at compile time  ie  LDOPTS  -lmylib for a library file named mylib so   The library must be present at compile time  and when the application starts  Static Library  A library that is merged into the actual program itself at build time for a single  larger  application containing the application code and the library code that is automatically linked into a program when the program is built  and the final binary containing both the main program and the library itself exists as a single standalone binary file  The library is included in the linking list at compile time  ie  LDOPTS  -lmylib for a library file named mylib a   The library must be present at compile time  DLL  Essentially the same as a shared object  but rather than being included in the linking list at compile time  the library is loaded via dlopen   dlsym   commands so that the library does not need to be present at build time for the program to compile  Also  the library does not need to be present  necessarily  at application startup or compile time  as it is only needed at the moment the dlopen dlsym calls are made  Shared Archive  Essentially the same as a static library  but is compiled with the  quot export-shared quot  and  quot -fPIC quot  flags  The library is included in the linking list at compile time  ie  LDOPTS  -lmylibS for a library file named mylibS a   The distinction between the two is that this additional flag is required if a shared object or DLL wants to statically link the shared archive into its own code AND be able to make the functions in the shared object available to other programs  rather than just using them internal to the DLL  This is useful in the case when someone provides you with a static library  and you wish to repackage it as an SO  The library must be present at compile time   Additional Update The distinction between  quot DLL quot  and  quot shared library quot  was just a  lazy  inaccurate  colloquialism in the company I worked in at the time  Windows developers being forced to shift to Linux development  and the term stuck   adhering to the descriptions noted above  Additionally  the trailing  quot S quot  literal after the library name  in the case of  quot shared archives quot  was just a convention used at that company  and not in the industry in general

User · Answer

You are correct in that static files are copied to the application at link-time, and that shared files are just verified at link time and loaded at runtime.

The dlopen call is not only for shared objects, if the application wishes to do so at runtime on its behalf, otherwise the shared objects are loaded automatically when the application starts. DLLS and .so are the same thing. the dlopen exists to add even more fine-grained dynamic loading abilities for processes. You dont have to use dlopen yourself to open/use the DLLs, that happens too at application startup.

User · Answer

I ve always thought that DLLs and shared objects are just different terms for the same thing - Windows calls them DLLs  while on UNIX systems they re shared objects  with the general term - dynamically linked library - covering both  even the function to open a  so on UNIX is called dlopen   after  dynamic library     They are indeed only linked at application startup  however your notion of verification against the header file is incorrect  The header file defines prototypes which are required in order to compile the code which uses the library  but at link time the linker looks inside the library itself to make sure the functions it needs are actually there  The linker has to find the function bodies somewhere at link time or it ll raise an error  It ALSO does that at runtime  because as you rightly point out the library itself might have changed since the program was compiled  This is why ABI stability is so important in platform libraries  as the ABI changing is what breaks existing programs compiled against older versions   Static libraries are just bundles of object files straight out of the compiler  just like the ones that you are building yourself as part of your project s compilation  so they get pulled in and fed to the linker in exactly the same way  and unused bits are dropped in exactly the same way

User · Answer

A static library  a  is a library that can be linked directly into the final executable produced by the linker it is contained in it and there is no need to have the library into the system where the executable will be deployed   A shared library  so  is a library that is linked but not embedded in the final executable  so will be loaded when the executable is launched and need to be present in the system where the executable is deployed   A dynamic link library on windows  dll  is like a shared library  so  on linux but there are some differences between the two implementations that are related to the OS  Windows vs Linux      A DLL can define two kinds of functions  exported and internal  The exported functions are intended to be called by other modules  as well as from within the DLL where they are defined  Internal functions are typically intended to be called only from within the DLL where they are defined    An SO library on Linux doesn t need special export statement to indicate exportable symbols  since all symbols are available to an interrogating process

User · Answer

I can elaborate on the details of DLLs in Windows to help clarify those mysteries to my friends here in  NIX-land     A DLL is like a Shared Object file  Both are images  ready to load into memory by the program loader of the respective OS  The images are accompanied by various bits of metadata to help linkers and loaders make the necessary associations and use the library of code   Windows DLLs have an export table  The exports can be by name  or by table position  numeric   The latter method is considered  old school  and is much more fragile -- rebuilding the DLL and changing the position of a function in the table will end in disaster  whereas there is no real issue if linking of entry points is by name  So  forget that as an issue  but just be aware it s there if you work with  dinosaur  code such as 3rd-party vendor libs   Windows DLLs are built by compiling and linking  just as you would for an EXE  executable application   but the DLL is meant to not stand alone  just like an SO is meant to be used by an application  either via dynamic loading  or by link-time binding  the reference to the SO is embedded in the application binary s metadata  and the OS program loader will auto-load the referenced SO s   DLLs can reference other DLLs  just as SOs can reference other SOs   In Windows  DLLs will make available only specific entry points  These are called  exports   The developer can either use a special compiler keyword to make a symbol an externally-visible  to other linkers and the dynamic loader   or the exports can be listed in a module-definition file which is used at link time when the DLL itself is being created  The modern practice is to decorate the function definition with the keyword to export the symbol name  It is also possible to create header files with keywords which will declare that symbol as one to be imported from a DLL outside the current compilation unit  Look up the keywords   declspec dllexport  and   declspec dllimport  for more information   One of the interesting features of DLLs is that they can declare a standard  upon load unload  handler function  Whenever the DLL is loaded or unloaded  the DLL can perform some initialization or cleanup  as the case may be  This maps nicely into having a DLL as an object-oriented resource manager  such as a device driver or shared object interface   When a developer wants to use an already-built DLL  she must either reference an  export library     LIB  created by the DLL developer when she created the DLL  or she must explicitly load the DLL at run time and request the entry point address by name via the LoadLibrary   and GetProcAddress   mechanisms  Most of the time  linking against a LIB file  which simply contains the linker metadata for the DLL s exported entry points  is the way DLLs get used  Dynamic loading is reserved typically for implementing  polymorphism  or  runtime configurability  in program behaviors  accessing add-ons or later-defined functionality  aka  plugins     The Windows way of doing things can cause some confusion at times  the system uses the  LIB extension to refer to both normal static libraries  archives  like POSIX   a files  and to the  export stub  libraries needed to bind an application to a DLL at link time  So  one should always look to see if a   LIB file has a same-named   DLL file  if not  chances are good that   LIB file is a static library archive  and not export binding metadata for a DLL

[c++] Difference between shared objects (.so), static libraries (.a), and DLL's (.so)?

Examples related to c++

Examples related to c

Examples related to linux

Examples related to dll

Examples related to linker