f



glibc 2.2.5 vs 2.3.2 on RH Enterprise

All executables on our development machine runnin RH Enterprise with glibc
2.2.5
are compiled statically. When we installed Enterprise 3 on our test machine
all executables as one started to crash with this stack:

(gdb) where
#0  0x080a67a1 in _dl_relocate_object ()
#1  0x0808d6b3 in dl_open_worker ()
#2  0x0808c28f in _dl_catch_error ()
#3  0x0808d8a7 in _dl_open ()
#4  0x080697ca in do_dlopen ()
#5  0x0808c28f in _dl_catch_error ()
#6  0x080696bd in __libc_dlopen ()
#7  0x08067dd6 in __nss_lookup_function ()
#8  0x0806845e in __nss_lookup ()
#9  0x08068657 in __nss_passwd_lookup ()
#10 0x08064568 in getpwuid_r ()
#11 0x08064243 in getpwuid ()
#12 0x080485ed in username ()

Short of dynamically linking all the executables and introduce dependency on
libc
installed on customer sites is there any way to make our programs work on
the systems
running glibc 2.2.5 and 2.3.2 while keep linking them statically?

If we install Enterprise v3 on our development box I'm aftraid the
executables
will stop to work on the systems that have glibc 2.2.5 installed. Would
they?
How robust is 2.3.2 compared to 2.2.5?

Do you have any suggestions on how to handles this?


0
John
11/18/2003 9:07:45 PM
comp.os.linux.development.apps 5216 articles. 1 followers. Post Follow

2 Replies
632 Views

Similar Articles

[PageSpeed] 1

"John Opezdol" <chungachanga@howdoesitsoundtoyou.au> wrote in message
news:vrl2h1h1etkn64@news.supernews.com...

> Short of dynamically linking all the executables and introduce dependency
on
> libc
> installed on customer sites is there any way to make our programs work on
> the systems
> running glibc 2.2.5 and 2.3.2 while keep linking them statically?

    Unfortunately, 'nss' pretty much has to dynamically link. This is the
best link on the issue that I could find quickly. But google for 'nss
dynamically link static' or similar.

 http://lists.debian.org/debian-glibc/2003/debian-glibc-200307/msg00235.html

    DS


0
David
11/18/2003 11:19:26 PM
John Opezdol wrote:
> All executables on our development machine running RH Enterprise with glibc
> 2.2.5 are compiled statically.
[snip]
> Short of dynamically linking all the executables and introduce dependency
> on libc installed on customer sites is there any way to make our programs
> work on the systems
> running glibc 2.2.5 and 2.3.2 while keep linking them statically?

When building apps, use the compat-gcc* packages to insure compatibility
with the library base of RH 7.3 (glibc 2.2.5).  Link everything dynamically,
and rely on the [supposed] forward/backward compatibility of each release
of the glibc suite as a whole.  If things break, then that's why
RH Enterprise Linux comes with Support.

If instead some static linking has been done, then try replacing each
/opt/foo/bin/app with an executable script something like
	#!/bin/bash
	LD_LIBRARY_PATH=/opt/foo/lib/2.2.5:$LD_LIBRARY_PATH  \
		exec /opt/foo/lib/app "$@"
where /opt/foo/lib/app is a copy of the old bin/app, and the lib/2.2.5
directory contains a copy of each library that is part of glibc-2.2.5,
namely: libc, libm, libdl, librt, libnss*, etc.  This still depends
on PT_INTERP /lib/ld-linux.so.2 being compatible across glibc releases,
and unfortunately this isn't always the case.  So you may have to
binary edit the fixed-length PT_INTERP string in lib/app to designate
/opt/foo/l225.so.2 which is a copy of [or a hard link to, or a symbolic
link to] ld-2.2.5.so (ld-linux.so.2 as of glibc-2.2.5.)

-- 

0
John
11/19/2003 5:54:12 AM
Reply: