Bug 111242

Summary: statically compiled gethostbyname compiled on RH 7 or earlier crashes on RH9
Product: [Retired] Red Hat Linux Reporter: David Jameson <davidj>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-12-02 14:37:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Simple test program which demonstrates the bug
none
stack trace for crash none

Description David Jameson 2003-12-01 09:42:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET 
CLR 1.1.4322)

Description of problem:
A statically linked executable compiled on RH7 or earlier crashes
in gethostbyname() on RH9. Happens both with a clean RH9 install
as well as with the latest glibc. It works okay if the program
is compiled statically on RH9. It appears to be an incompatibility
with the nss_files.so static hack (which works with all previous
versions of Linux right back to pre-glibc2 versions).

Version-Release number of selected component (if applicable):
2.3.2-27.9.7

How reproducible:
Always

Steps to Reproduce:
1. (on RH7): g++ -static tester.cpp
2. (on RH9): ./a.out test.com
3.
    

Actual Results:  Segmentation fault

Expected Results:  208.48.34.132


Additional info:

Comment 1 David Jameson 2003-12-01 09:42:44 UTC
Created attachment 96255 [details]
Simple test program which demonstrates the bug

Comment 2 David Jameson 2003-12-01 09:43:09 UTC
Created attachment 96256 [details]
stack trace for crash

Comment 3 Jakub Jelinek 2003-12-02 14:37:50 UTC
This is expected and when you link against recent glibcs it even
warns you about it.
If a program uses NSS/iconv/dlopen or locales, it is not self-contained
and as such can be only used against the same glibc as it has been
compiled/linked against.
Better avoid statically linked programs, dynamically linked ones
are way more portable.