Bug 68606 - symbol _dl_loaded, version GLIBC_2.1 not defined in ld-linux.so.2 in Redhat 7.3
Summary: symbol _dl_loaded, version GLIBC_2.1 not defined in ld-linux.so.2 in Redhat 7.3
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-07-11 17:28 UTC by Brian ven der Buhs
Modified: 2016-11-24 15:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-07-11 17:28:32 UTC
Embargoed:


Attachments (Terms of Use)

Description Brian ven der Buhs 2002-07-11 17:28:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408

Description of problem:
Redhat 7.2 and 7.1 glibc/ld libraries supported the _dl_loaded symbol.
Stock gnu glibc-2.2.5 also supports the symbol.
Redhat 7.3's glibc-2.2.5-34 and 2.2.5-36 seem to not support the symbol.
A workaround is required to enable an older application to run 
while the vendor works to recode to the new standards.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.On Redhat 7.3, the following command
  readelf -s /lib/libc.so.6 /lib/ld-linux.so.2 | grep _dl_loaded
  returns nothing
2.Using the stock gnu 2.2.5 distribution, the following command:
  cd /tmp/stockgnu-glibc-2.2.5-build 
  readelf -s libc.so.6 elf/ld-linux.so.2 | grep _dl_loaded
  returns the following results:
  1423: 00000000     4 OBJECT  GLOBAL DEFAULT  UND _dl_loaded (16)
  4801: 00000000     4 OBJECT  GLOBAL DEFAULT  UND _dl_loaded@@GLIBC_2.1
    77: 000148d0     4 OBJECT  GLOBAL DEFAULT   14 _dl_loaded@@GLIBC_2.1
   409: 000148d0     4 OBJECT  GLOBAL DEFAULT   14 _dl_loaded
3.Similarly, on a Redhat 7.2 the following command:
  readelf -s /lib/libc.so.6 /lib/ld-linux.so.2 | grep _dl_loaded
  produces the following output:
  1429: 00000000     4 OBJECT  GLOBAL DEFAULT  UND _dl_loaded (15)
    97: 00016bc4     4 OBJECT  GLOBAL DEFAULT   15 _dl_loaded@@GLIBC_2.1
   380: 00016bc4     4 OBJECT  GLOBAL DEFAULT   15 _dl_loaded
	

Actual Results:  Older applications that require _dl_loaded need to be able
to find it in order to run.

I took the 2.2.5-36 src rpm and modified elf/Versions to declare
the symbol, however, after rebuilding the rpm, there is no difference.
This approach mimics what is done in the stock gnu distribution.
I may be missing something and could use a pointer.

Expected Results:  I was hoping to make a small change to the 2.2.5-36 source rpm
and create a functionally equivalent, but slightly more backward
compatible glibc/ld.  However, I am not a code cruncher so
I seem to have hit a wall.
Is there a way I can achieve my goal using this tactic?
Is this route not feasible and a waste of time?
Is there another workaround that will achieve my goal?
How do I expose this symbol for an older application?

Additional info:

This "bug" seems similar to bugs 66278, 65372, 65449.
Also, the libc-hacker mail list has a Jan 30/31, 2002
thread regarding ld.so changes that describe the demise of
_dl_loaded.

I realize that the most obvious workaround is to downgrade
to Redhat 7.2 until the vendor releases a compatible
version of their software, but I'd like to avoid that if there is a
straightforward workaround.

Any and all help will be appreciated.

Thanks,

Brian ven der Buhs

Comment 1 Jakub Jelinek 2002-07-18 09:01:23 UTC
_dl_loaded was never a supported symbol in glibc, it has been always a private
glibc symbol which application had no businness of ever touching.
If they do so, it is their bug and as such needs to be fixed.
You can certainly try to build a small shared library defining symbol _dl_loaded@@GLIBC_2.1
and LD_PRELOAD it to the application, assuming it will work properly if it
contains NULL chain. The supported interface for walking through the list
of loaded libraries is dl_iterate_phdr(3).

Comment 2 Brian ven der Buhs 2002-07-18 16:41:48 UTC
Jakub,

This should give us enough information to get a temporary solution in place.
The vendor will likely support RH 7.3/glibc-2.2.5-36 in a future release and this
pointer may be useful for them as well.

Thanks,

Brian


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