After upgrading glibc from 2.11.3 to 2.12.2 the following C when compiled to a statically linked executable produces different results: #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <string.h> #include <unistd.h> #include <sys/types.h> #include <pwd.h> int main(int argc, char *argv[]) { uid_t uid; struct passwd *pw; uid=getuid(); errno=0; pw=getpwuid(uid); if(pw==0) { fprintf(stderr, "getpwuid: %s\n", strerror(errno)); exit(EXIT_FAILURE); } fprintf(stdout, "uid = %d name = %s\n", uid, pw->pw_name); exit(EXIT_SUCCESS); } Reproducible: Always Steps to Reproduce: 1. Save above code to getpwuid.c 2. on glibc 2.11.3 system: gcc -static -o getpwuid.static getpwuid.c 3. : ./getpwuid.static 4. on glibc 2.12.2 system: gcc -static -o getpwuid.static getpwuid.c 5. : ./getpwuid.static 6. on glibc 2.12.2 system: gcc -o getpwuid getpwuid.c : ./getpwuid Actual Results: glibc-2.11.3$ gcc -static -o getpwuid.static getpwuid.c /tmp/ccKRYLRk.o: In function `main': getpwuid.c:(.text+0x29): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking glibc-2.11.3$ ./getpwuid.static uid = 1000 name = pod glibc-2.12.2$ gcc -static -o getpwuid.static getpwuid.c /tmp/ccAhUuVs.o: In function `main': getpwuid.c:(.text+0x29): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking glibc-2.12.2$ ./getpwuid.static getpwuid: Success glibc-2.12.2$ gcc -o getpwuid getpwuid.c glibc-2.12.2$ ./getpwuid uid = 1000 name = pod Expected Results: The uid and username of the invoker ought to be written to stdout in all cases. Supplementary: it seems like a bug that if one accepts that getpwuid() is going to return NULL in the static linking case then errno should also be set to something non-zero. man getpwuid says: The getpwnam() and getpwuid() functions return a pointer to a passwd structure, or NULL if the match- ing entry is not found or an error occurs. If an error occurs, errno is set appropriately. If one wants to check errno after the call, it should be set to zero before the call. Demonstrating the regression is a real pain since glibc upgrades are a one way ratchet. It's pure luck that I happen to have access to two similar systems and that I had not upgraded both before noticing the issue and was thus able to convince myself that the behaviour had changed. I have neither the desire nor will to debate the politics/benfits/drawbacks of static linking :-)
known issue. dont use static linking.
*** Bug 368391 has been marked as a duplicate of this bug. ***
Spanky: Thanks for the update to my bug :) Do you have a reference to whom/where the issue is known? - e.g. does upstream know about this? Do you know if someone is working on it - or - will I have to live without a static openssh version for a (very long?) while now? And finally I am wondering: If this a known issue: It is possible to mask useflags for packages, right? --> Wouldn't it be a good idea to mask the "static" useflags for packages like openssh?
read the URL i linked in already
The same result with getpwnam(), getpwnam_r(), etc. NSS is pluggable, it loads nss_compat.so, etc. on the fly => static linking may not work even if the bug is resolved. This bug causes a lot of troubles, because many programs use this call. I had problems with daemontools and runit, for instance.
*** Bug 379565 has been marked as a duplicate of this bug. ***
*** Bug 379567 has been marked as a duplicate of this bug. ***
*** Bug 384153 has been marked as a duplicate of this bug. ***
this will be fixed in glibc-2.15. not sure if i'll try and cut a patch for glibc-2.1{2,3,4}* though ...
glibc-2.15 is in the tree now
*** Bug 414843 has been marked as a duplicate of this bug. ***
I don't think this is fixed. I get the same "no such user"/"no such group" id/chgrp issue on a stable-keyworded amd64 Gentoo system installed yesterday with USE=static. Latest stable glibc is 2.19-r1.
(In reply to Jaak Ristioja from comment #12) please file a new bug with exact details as to how to reproduce it
