Bug 111242 - statically compiled gethostbyname compiled on RH 7 or earlier crashes on RH9
Summary: statically compiled gethostbyname compiled on RH 7 or earlier crashes on RH9
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 9
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-12-01 09:42 UTC by David Jameson
Modified: 2016-11-24 14:58 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-12-02 14:37:50 UTC
Embargoed:


Attachments (Terms of Use)
Simple test program which demonstrates the bug (384 bytes, text/plain)
2003-12-01 09:42 UTC, David Jameson
no flags Details
stack trace for crash (1.62 KB, text/plain)
2003-12-01 09:43 UTC, David Jameson
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.