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