[prev in list] [next in list] [prev in thread] [next in thread] 

List:       redhat-devel
Subject:    Re: Static linking, but resolv libraries needed in chrooted environment?
From:       Jonathan Sergent <sergent () home ! com>
Date:       1998-11-21 0:15:11
[Download RAW message or body]

In message <Pine.BSI.3.95.981120154012.6196B-100000@rocky.orci.com>, Mike Blatc
hley writes:
 ] But then, "nm --undefined smap" returns:
 ]   __gmon_start__
 ]   __nss_aliases_database
 ]   __nss_ethers_database

(snip)

 ] To get this to execute, I have put lib's such as ld, ld-linux, libc,
 ] libnsl, libnss*, libresolv in the chrooted environment, but I'd like to
 ] eliminate this need.  Apparently these still will be dynamically linked on
 ] execution.  Anybody know how to get these wrapped into the executable on a
 ] Linux machine; I've talked with people running similar applications on
 ] different architectures, and they havn't had this problem. 

I think this is because the name service switch dynamically loads the 
name service so's at runtime based on what's in /etc/nsswitch.conf.  At 
least that's the case with Solaris -- you can link things statically
but if they do name lookups they aren't _actually_ static.

I don't think there's anything you can do about this short of using an 
old libc that didn't have the name service switch, or making the program
not use the resolver library in glibc.

(I might be spewing nonsense here, because I haven't actually looked
at the code or docs in question to verify this; it's just from 
recollection...)


-- 
Jonathan Sergent / sergent@etla.net

-- 
To unsubscribe:
mail -s unsubscribe redhat-devel-list-request@redhat.com < /dev/null

[prev in list] [next in list] [prev in thread] [next in thread]