Bug 111298 - static linking results in warnings (and nonportable code)
Summary: static linking results in warnings (and nonportable code)
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc
Version: 3.0
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-12-01 20:24 UTC by Need Real Name
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2003-12-01 22:49:41 UTC


Attachments (Terms of Use)
Example program (114 bytes, text/plain)
2003-12-01 20:26 UTC, Need Real Name
no flags Details

Description Need Real Name 2003-12-01 20:24:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007

Description of problem:
Static linking of programs containing calls to gethostbyname,
getserverbyname, getpwnam, and probably others, results in a link time
warning (see end of description.)  When I try to run the resulting
objects on older systems (say RH 7.3) they get illegal instruction
interupts.

Static linking of the very same programs on RH 9 systems causes no
warnings and the resulting binaries seem to work on older linux systems.

So what's the difference?

The link time warnings:

../services/os/libos.a(os.o)(.text+0x247a): In function
`os_lose_root(char*)':
../../../dev/src/services/os/os.c:634: Using 'getpwnam' in statically
linked applications requires at runtime the sha\
red libraries from the glibc version used for linking
../external/C/openssl/lib/libcrypto.a(b_sock.o)(.text+0x339): In
function `BIO_gethostbyname':
: Using 'gethostbyname' in statically linked applications requires at
runtime the shared libraries from the glibc ver\
sion used for linking
../services/util/libutil_product.a(sockutil.o)(.gnu.linkonce.t._ZN12HOST_BY_NAMEC1EPKc+0x45):
In function `HOST_BY_NA\
ME::HOST_BY_NAME(char const*)':
/usr/local/gcc-3.3.2/include/c++/3.3.2/bits/stl_tree.h:748: Using
'gethostbyname_r' in statically linked applications\
 requires at runtime the shared libraries from the glibc version used
for linking
../external/C/openssl/lib/libcrypto.a(b_sock.o)(.text+0x18c): In
function `BIO_get_port':
: Using 'getservbyname' in statically linked applications requires at
runtime the shared libraries from the glibc ver\
sion used for linking


Version-Release number of selected component (if applicable):
glibc-2.3.2-95.6 binutils-2.14.90.0.4-26 gcc-3.2.3-20

How reproducible:
Always

Steps to Reproduce:
1. gcc -static x.c (I'll supply x.c as an attachment.)
2. copy a.out to a 7.3 system
3. a.out
    

Actual Results:  illegal instruction

Expected Results:  No output

Additional info:

Comment 1 Need Real Name 2003-12-01 20:26:20 UTC
Created attachment 96264 [details]
Example program

Comment 2 Jakub Jelinek 2003-12-01 22:49:41 UTC
If a RHL9 built statically linked binary using NSS works on older
glibcs, then you are just lucky, nothing else.  It certainly will not
work on all older glibcs, only on some and only under some circumstances.
Statically linked programs which are not self-contained and depend
on the installed glibc (be it because of using NSS or iconv (which
both dlopen glibc internally), using dlopen directly or even using
locale support) are really the least portable thing you can build.

Dynamically linking is uncomparably more portable.
You can link some libraries statically using -Bstatic -lfoo -lbar -Bdynamic,
yet link against the crucial system libraries dynamically.

The warnings were added so that everyone is aware of the problems
with -static.  For statically linked binaries using NSS/iconv/dlopen
the dynamic linker needs to be compiled into the statically linked
program, yet the shared libraries it loads come from a different
glibc if the statically linked binary is moved onto a different system.
This means the glibc private interface between the dynamic linker
and libc.so/libpthread.so is exposed, but this interface is constantly
changing (and has been changing for years in the past as well).

So, the only supported way of using NSS/iconv/dlopen in statically
linked programs is if they are compiled/linked against the same glibc
as they are run with.


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