Bug 112707 - dynamic-link.h:57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed.
dynamic-link.h:57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-29 06:30 EST by Christopher Stone
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-29 06:45:30 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)

  None (edit)
Description Christopher Stone 2003-12-29 06:30:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031110 Firebird/0.7

Description of problem:
I get the following error when loki_update tries to install an update:

dynamic-link.h:57: elf_get_dynamic_info: Assertion `! "bad dynamic
tag"' failed.

I also get the same error when I try to run Kohan (by loki) because it
seems Kohan tries to run the Loki QAgent support tool upon execution.

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

How reproducible:
Always

Steps to Reproduce:
1.  Run kohan (by loki) or..
2.  Run loki_update and try to update a loki product.

    

Actual Results:  Application crashes with error message:

dynamic-link.h:57: elf_get_dynamic_info: Assertion `! "bad dynamic
tag"' failed.

Expected Results:  Program runs normally.

Additional info:

I tried setting LD_ASSUME_KERNEL to different values, but this did not
help.
Comment 1 Jakub Jelinek 2003-12-29 06:45:30 EST
You are trying to run statically linked binaries which use NSS/dlopen/iconv
and have been built against very old glibcs.
This is not going to work, such programs were never portable, if they
are able to run against glibc other than the exact version they have
been compiled against, it is just by luck.
The problem is that those statically linked binaries have their copy
of the dynamic linker linked into them, and that copy isn't able to 
cope with current glibc.
Current glibc warns at link time about such programs, so that developers
are aware of the limitations of not-fully self-contained statically linked
programs.
Ask Loki to avoid using statically linked binaries.  -Bstatic ... -Bdynamic
is way preferred, that way one can decide what libraries should be linked
into the program and what libraries are linked dynamically.  Certainly,
libc.so, libpthread.so, ld-linux.so should be always linked dynamically.

As a workaround, you could try unpacking some old glibc into some directory,
say ~/oldglibc/lib and then run the statically linked program with
LD_LIBRARY_PATH=~/oldglibc/lib ./statically_linked_program
This certainly will not work if the statically linked program tries
to execute some dynamically linked program though.

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