Bug 111298
| Summary: | static linking results in warnings (and nonportable code) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Need Real Name <rutt> | ||||
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.0 | CC: | barryn | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2003-12-01 22:49:41 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: |
|
||||||
Created attachment 96264 [details]
Example program
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. |
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: