glibc-2.3.1: Segfault when nis compiled with "- static"

[Srikrishnan Sundararajan]

Hi,
Here is some additional info and few more questions for my earlier post.
1. I am compiling my application calling getpwuid with "- static".  I
understand that while using nss, even a statically linked binary calls a
few shared libraries. When I observe /proc/<pid>/maps I find that even
libc.so, ld.so etc get "mapped". Upon trying to disassemble, I find that
they are not really present in the address where they are shown to be
"mapped".

This also seems to be the reason, why when I call getpwuid, using NIS
"compat" mode, attempt to call _nss_compat_getpwuid_r in libnss_compat.so
results in segfault(SIGSEGV), as it is not in the address returned by
nss_lookup.

2. Is it that segfault is expected to occur in the above scenario? Is the
only way out to compile glibc with "static-nss" option?

Please note that I had been trying to compile and run my application using
the same glibc version (glibc-2.3.1) on the same machine (I am using the
same glibc which  I compiled on the same machine. )

While running the application after dynamically linking, no problems occur.

Any help would be appreciated.

Srikrishnan


It is the same problem as in the following post:
 static binary doing getpwuid() or such
      + "passwd: compat" in /etc/nsswitch.conf
      + "address@hidden::::::" in /etc/passwd
      = crash.

I am used my compiled version of glibc-2.3.1 on Linux/i386. I am compling
with "-static" and executing my program on the same machine(NIS client with
compat mode). The test program just calls getpwuid, I get a segfault.

I have not be able to see any proper solution while looking at the previous
posts. Upon using gdb, I found that DB_LOOKUP_FCT is called. Here
nss_compat is loaded using dl_open and the address for the function is
nss_compat_getpwuid_r is looked up (nss_lookup_function -> lib_dlsym ->
dl_sym).

Then DL_CALL_FCT is called with the function address returned. This in turn
calls dl_mcount from elf/dl-profstub.c:42. Soon, segfault occurs.

 /proc/<pid>/maps shows that the nss_compat has been mapped around the
place for which I get "??" in backtrace after the segfault.

1. Is this a known problem, has it been fixed?
2. I am compling as well as and executing the program on the same machine
with the same glibc-2.3.1?
Any other help or suggestions in zeroing in on the problem would be
helpful.


Thanks,
Srikrishnan