When creating a class library in C++, you can choose between dynamic (`.dll`, `.so`) and static (`.lib`, `.a`) libraries. What is the difference between them and when is it appropriate to use which?

When to use dynamic vs. static libraries

Are there any compelling performance reasons to choose static linking over dynamic linking or vice versa in certain situations? I&#39;ve heard or read the following, but I don&#39;t know enough on the subject to vouch for its veracity.

1) The difference in runtime performance between static linking and dynamic linking is usually negligible.

2) (1) is not true if using a profiling compiler that uses profile data to optimize program hotpaths because with static linking, the compiler can optimize both your code and the library code. With dynamic linking only your code can be optimized. If most of the time is spent running library code, this can make a big difference. Otherwise, (1) still applies.

Static linking vs dynamic linking

I often hear the terms &#39;statically linked&#39; and &#39;dynamically linked&#39;, often in reference to code written in [C][1], [C++][2] or [C#][3]. What are they, what exactly are they talking about, and what are they linking?

  [1]: http://en.wikipedia.org/wiki/C_%28programming_language%29
  [2]: https://en.wikipedia.org/wiki/C++
  [3]: http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29


What do &#39;statically linked&#39; and &#39;dynamically linked&#39; mean?

I am having a little trouble working with static methods in C++

Example .h:

    class IC_Utility {
	public:
		IC_Utility();
		~IC_Utility();
		
		std::string CP_PStringToString( const unsigned char *outString );
		void CP_StringToPString( std::string&amp; inString, unsigned char *outString, short inMaxLength );
		static void CP_StringToPString( std::string&amp; inString, unsigned char *outString);
		void CP_StringToPString( FxString&amp; inString, FxUChar *outString);

    };

Example .cpp:

    static void IC_Utility::CP_StringToPString(std::string&amp; inString, unsigned char *outString)
    {
	    short		length = inString.length();
	
	   if( outString != NULL )
	    {
		    if( length &gt;= 1 )
			    CPLAT::CP_Utility::CP_CopyMemory( inString.c_str(), &amp;outString[ 1 ], length );
		
	    	    outString[ 0 ] = length;
	    }
    }

I wanted to make a call like:

    IC_Utility::CP_StringToPString(directoryNameString, directoryName );

But I get an error:

    error: cannot declare member function &#39;static void IC_Utility::CP_StringToPString(std::string&amp;, unsigned char*)&#39; to have static linkage

I dont understand why I cannot do this. Can anyone help me understand why and how to achieve what I want?


Define static method in source-file with declaration in header-file in C++

Even trivially small Haskell programs turn into gigantic executables. 

I&#39;ve written a small program, that was compiled (with GHC) to the binary with the size extending 7 MB! 

What can cause even a small Haskell program to be compiled to the huge binary?

What, if anything, can I do to reduce this?



Small Haskell program compiled with GHC into huge binary

I have to admit that with the release of iOS 8 I am a bit confused about dynamic and static frameworks in iOS.

I am looking for a way to distribute a library that I created, and I need to support iOS 7 and above. (Note: This will be a proprietary framework. I cannot use cocoa pods, and I also cannot distribute the source). Here is what I already know:

- iOS 8 introduced &quot;embedded frameworks&quot; for iOS, but, as I understand, they do not work for iOS 7, only for iOS 8 and above.
- I have the option of distributing my library as a static library (.a file) and also distribute the headers. I know that this is a common way of dealing with the situation, but I would like to find something simpler than that (and also to bundle some resources with it, if possible).
- I have also found that iOS 7 does not support dynamic .framework libraries (only static) because it doesn&#39;t support dynamic linking. But iOS 8 does, as well as static linking.

And here are my questions regarding this information:

- I saw that I can create a .framework target, and make it static, by changing the Mach-O type to &quot;static library. Would that be enough in order to support iOS 7 without any problems, and also to distribute my library as a .framework bundle? If so, why is &quot;embedded frameworks&quot; in iOS 8 that big of a deal, as many resources on the internet are suggesting? Am I missing something?
- Is it necessary to codesign the .framework just as I do with any other application I make?
- What if I need to include other resources (like Core Data or Images) with my .framework file? Will I need to make a separate .bundle file for that?

iOS Static vs Dynamic frameworks clarifications

I have a problem with linking my mixed language framework to a project.&lt;p&gt;
1. I create a framework with Swift and Objective-C classes.
1. The main logic was stored in the Swift file. For example the class with a method that calls NSLog(&quot;Swift log was called&quot;).
1. Objective-C file has a class that has a method in which I create an instance of Swift class and call Swift-log method.
1. I link this framework with my Objective-C project, I can call all that I need in this project, but when I want to build this project I receive error `linker command failed with exit code 1 (use -v to see invocation)`
  
    And warnings:
```
ld: warning: Could not find auto-linked library &#39;swiftFoundation&#39;
ld: warning: Could not find auto-linked library &#39;swiftDarwin&#39;
ld: warning: Could not find auto-linked library &#39;swiftCoreFoundation&#39;
ld: warning: Could not find auto-linked library &#39;swiftCore&#39;
ld: warning: Could not find auto-linked library &#39;swiftCoreGraphics&#39;
ld: warning: Could not find auto-linked library &#39;swiftObjectiveC&#39;
ld: warning: Could not find auto-linked library &#39;swiftDispatch&#39;
ld: warning: Could not find auto-linked library &#39;swiftSwiftOnoneSupport&#39;
```

I also saw the solution with importing empty Swift-file, but it necessary to make a project without any trash.

Why do I get iOS linker errors with my static libraries?

I have read on the web that following combination exists : 

**Proprietary Source code + GPL Source code** - &gt; GPL Source code ( All code has to be released under GPL)

**Proprietary Source code + LGPL Source code** - &gt; Proprietary Source code ( All code remains Proprietary )

Now how does **statically/Dynamically** linking GPL and LGPL code works with the above combination?

GPL/LGPL and Static Linking

In fact, *-static* gcc flag on Linux doesn&#39;t work now. Let me cite from the GNU libc FAQ:

&gt; **2.22. Even statically linked programs need some shared libraries
&gt; which is not acceptable for me. What
&gt; can I do?**
&gt; 
&gt; {AJ} NSS (for details just type `info
&gt; libc &quot;Name Service Switch&quot;&#39;) won&#39;t
&gt; work properly without shared
&gt; libraries.  NSS allows using different
&gt; services (e.g. NIS, files, db, hesiod)
&gt; by just changing one configuration
&gt; file (/etc/nsswitch.conf) without
&gt; relinking any programs.  The only 
&gt; disadvantage is that now static
&gt; libraries need to access shared 
&gt; libraries.  This is handled
&gt; transparently by the GNU C library. 
&gt; 
&gt; A solution is to configure glibc with
&gt; --enable-static-nss.  In this case you can create a static binary that will
&gt; use only the services dns and files
&gt; (change /etc/nsswitch.conf for this).
&gt; You need to link explicitly against
&gt; all these services. For example:
&gt;  
&gt; 
&gt;      gcc -static test-netdb.c -o test-netdb \
&gt;        -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group
&gt; 
&gt;   The problem with this approach is
&gt; that you&#39;ve got to link every static
&gt; program that uses NSS routines with
&gt; all those libraries.  
&gt; **{UD} In fact, one cannot say anymore that a libc compiled with this option
&gt; is using NSS.  There is no switch
&gt; anymore.  Therefore it is *highly*
&gt; recommended *not* to use
&gt; --enable-static-nss since this makes the behaviour of the programs on the
&gt; system inconsistent.**

Concerning that fact is there any reasonable way now to create a full-functioning static build on Linux or static linking is completely dead on Linux? I mean static build which:

 - Behaves exactly the same way as
   dynamic build do (static-nss with
   inconsistent behaviour is evil!);
 - Works on reasonable variations of glibc environment and Linux versions;



Linux static linking is dead?

Most of the sources online state that you can statically link glibc, but discourage from doing so; e.g. [centos package repo](https://centos.pkgs.org/7/centos-updates-x86_64/glibc-static-2.17-260.el7_6.4.x86_64.rpm.html):

&gt; The glibc-static package contains the C library static libraries
for -static linking.  You don&#39;t need these, unless you link statically, which is highly discouraged.

These sources rarely (or never) say why that would be a bad idea.

Why is statically linking glibc discouraged?

I&#39;ve had numerous problems compiling shared objects that link statically against static libraries. This problem only shows up on x84_64 platforms. When doing the same compilation work on x86_32 I do not have any problems. 

Perhaps this is a OS specific GCC configuration thing, but my research indicates that its how GCC works on x86_64 platforms. Anyhow, I am using gcc 4.4.3 on Ubuntu 10.04 x86_64.

How is the problem fixed ?... Making sure all the static library dependencies are compiled with -fPIC.

**Question 1:** What is the difference between -fpic and -fPIC (apparently -fPIC generates more instructions on x86) ? Why is the later type more relevant in the x86_64 context ? 

**Question 2:** My assumption is that when you link against static code you are hard-wiring the functions into your binary at link time, why does it need the level of indirection the &quot;position independant code&quot; machinery provides ? 

**Question 3:** Now if x86 doesn&#39;t need -fpic / -fPIC to link shared objects against static archives why is it needed in x86_64 ? 

**Question 4:** even if it is needed why isn&#39;t it supplied implicitly ? I thought breaking changes was supposed to be a big no-no

Why does gcc not implicitly supply the -fPIC flag when compiling static libraries on x86_64

I have a static library file called `libunp.a`, I do know I could use `gcc -lunp xx` to link to the library.

I could use `#pragma comment(lib,&quot;xxx.lib&quot;)` to tell the Microsoft C/C++ compiler to include the library; how could I do it under Linux/GCC?

#pragma comment(lib, &quot;xxx.lib&quot;) equivalent under Linux?

I use mingw from here: `http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/32-bit/threads-posix/sjlj/x32-4.7.2-release-posix-sjlj-rev2.7z/download`

And I&#39;ve sucessfully managed to link statically `libstdc++-6.dll` and `libgcc_s_sjlj-1.dll` by using `-static-libgcc -static-libstdc++` parameters, but I cannot find a command for doing the same with `libwinpthread-1.dll`.

how to do static linking of libwinpthread-1.dll in mingw?

This might sound like a silly question but If you have a thirdParty.framework file, can you tell if it&#39;s static or dynamic? I mean, do they look different if you look inside?

iOS is it a static or a dynamic framework?

I am trying to create a static executable with Rust. I am *not* trying to statically link a particular library, I am trying to create a executable which *does not use dynamic linking at all*. I have the following (otherwise working) test:

    $ cat hello.rs
    fn main()
        {
        print!(&quot;Hello, world!\n&quot;);
        }
    $ rustc hello.rs -o hello
    $ file hello
    hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
     dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, [etc]

Note the `dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2`. Static executables have `statically linked` instead. (And in my case `corrupted section header size`, although I would be pleasantly astonished if I can convince Rust to replicate *that*.)

What options do I need to pass to `rustc` to get it to generate a actual static executable (for concreteness: one which even `file` agrees is statically linked).


How to generate statically linked executables?

I would like to have control over the type of the libraries that get found/linked with my binaries in CMake. The final goal is, to generate binaries _&quot;as static as possible&quot;_ that is to link statically against every library that does have a static version available. This is important as would enable portability of binaries across different systems during testing. 

ATM this seems to be quite difficult to achieve as the FindXXX.cmake packages, or more precisely the find_library command always picks up the dynamic libraries whenever both static and dynamic are available. 

Tips on how to implement this functionality - preferably in an elegant way - would be very welcome!

CMake: how to produce binaries &quot;as static as possible&quot;

Recently, I switched to Xcode4 and when I compile my project I got following error.

    ld: warning: ignoring file /Users/myname/Library/Developer/Xcode/DerivedData/appname-hezrgyqimckztgbdlslkavphdclw/Build/Products/Debug-iphoneos/libTapkuLibrary.a, file was built for archive which is not the architecture being linked (armv6)
    Undefined symbols for architecture armv6:
      &quot;_OBJC_CLASS_$_TKLoadingView&quot;, referenced from:
          objc-class-ref in RootViewController.o

I opened the TapkuLibrary and checked that it&#39;s Architectures set to &#39;Standard (armv6 armv7)&#39;.

What can I do to fix this problem?


All Static Linking Solutions on Gang of Coders

Total of 17 Static Linking Solutions