From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11610 invoked by alias); 12 Apr 2005 11:27:28 -0000 Mailing-List: contact glibc-bugs-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sources.redhat.com Received: (qmail 11575 invoked by uid 48); 12 Apr 2005 11:27:21 -0000 Date: Tue, 12 Apr 2005 11:27:00 -0000 From: "egmont at uhulinux dot hu" To: glibc-bugs@sources.redhat.com Message-ID: <20050412112708.842.egmont@uhulinux.hu> Reply-To: sourceware-bugzilla@sources.redhat.com Subject: [Bug nptl/842] New: getpid() not working with statically linking X-Bugzilla-Reason: CC X-SW-Source: 2005-04/txt/msg00095.txt.bz2 List-Id: I have a simple program (attached) that only performs a getpid() call and prints its return value. This works perfectly if I link it dynamically, but returns constant 5 if it's statically linked. egmont $ gcc -Wall -O2 -o getpid getpid.c egmont $ ./getpid ; ./getpid 4166 4167 egmont $ gcc -Wall -O2 -static -o getpid getpid.c egmont $ ./getpid ; ./getpid 5 5 According to strace, the getpid() system call is not executed at all in the second case. So I have a feeling that perhaps the internal cache for the PID might remain uninitialized. Details concerning glibc: I tried and faced this bug with two different version, one is 20041021T0701 as found inside the Fedora Core 3 source RPM (but I did not use the Fedora binary, I recompiled their cvs snapshot source tarball, without using their additional tarballs or patches), the other version is the official 2.3.5 tarball. How I compiled: rm -rf linuxthreads linuxthreads_db cd /path/to/objectdir /path/to/source/configure \ --with-tls --enable-add-ons \ --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ --mandir=/usr/share/man --infodir=/usr/share/info \ --enable-shared \ --build=i586-uhu-linux --host=i586-uhu-linux make user-defined-trusted-dirs=/usr/local/lib So I have absolutely no sign of linuxthreads, only nptl, installed directly to /lib (.so) and /usr/lib (.a). No subdirectory under /lib or /usr/lib that contains any libc-related files (that is, no subdirectory called i?86, tls, nptl or similar) exists. /usr/lib/libc.a is definitely nptl-version, an "nm" on it shows two __nptl_... symbols. I have found several issues with getpid() on the net, including this bugzilla, all related to nptl, but all those I've found are said to be already fixed, however, this one is misbehaving for me right now. On the other hand, the getppid() call always works perfectly for me. Other details: $ scripts/config.guess # from glibc's source i686-pc-linux-gnu $ uname -a Linux bobek 2.6.9-19 #1 SMP Thu Jan 27 08:52:43 CET 2005 i686 unknown unknown UHU-Linux $ gcc -v Reading specs from /usr/lib/gcc-lib/i586-uhu-linux/3.3.4/specs Configured with: /var/uhubuild/work/compile/configure --prefix=/usr --infodir=/ usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,objc,java,f77, pascal --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib -- host=i586-uhu-linux Thread model: posix gcc version 3.3.4 $ ld -v GNU ld version 2.15 -- Summary: getpid() not working with statically linking Product: glibc Version: 2.3.4 Status: NEW Severity: normal Priority: P2 Component: nptl AssignedTo: drepper at redhat dot com ReportedBy: egmont at uhulinux dot hu CC: glibc-bugs at sources dot redhat dot com http://sources.redhat.com/bugzilla/show_bug.cgi?id=842 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.