Bug 111298 - static linking results in warnings (and nonportable code)
static linking results in warnings (and nonportable code)
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-01 15:24 EST by Need Real Name
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-01 17:49:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Need Real Name 2003-12-01 15:24:53 EST
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 15:26:20 EST
Created attachment 96264 [details]
Example program
Comment 2 Jakub Jelinek 2003-12-01 17:49:41 EST
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.