On 8/16/2011 1:58 PM, Bryan Ischo wrote:
On 08/16/11 10:40, Carlos O'Donell wrote:
On 8/16/2011 12:28 PM, Bryan Ischo wrote:
I would personally avoid linking statically.
Install the new libraries to /opt/sysroot/, and build your
applications with -Wl,--dynamic-linker=/opt/sysroot/lib/ld.so.1
and the appropriate -Wl,-rpath=....
Thank you for the suggestion, and I appreciate the advice. Just
curious - what is the harm in static linking? Larger memory
footprint of the compiler, but I doubt that would even be noticed
in this day and age of 12 GB development systems ...
(1) Eventually something calls dlopen and then you probably get the
wrong runtime.
Are you talking about something within the compiler toolchain itself?
I have disabled plugins in gcc to avoid the use of dlopen there (and
we don't use any of the gcc plugins so this has no drawback for us);
I wonder where else dlopen might be used? I must make a note to
examine the built toolchain to look for references to dlopen ...
If you aren't strict about the applications that you put in your
environment, eventually one of them may include a call to dlopen,
and that could be a problem. You will need to audit the applications
you link statically to ensure that they don't call dlopen.
(2) Static linking isn't static if you access the network since NSS
uses dlopen.
Sorry I am unfamilar with NSS; is this something that is used by the
compiler toolchain itself? If so, I wonder when/if we'd ever make
use of such functionality.
NSS is the framework that glibc uses internally to provide name
resolution services and that framework internally uses dlopen to
open plugins to access the various databases. Therefore any
static application that has to do a network name lookup is going
to use dlopen indirectly via glibc. That technically makes the
application non-static, and it requires a properly installed
runtime to work.