Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1061432 - libdwarf is not linked to libelf
Summary: libdwarf is not linked to libelf
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libdwarf
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1061501
TreeView+ depends on / blocked
 
Reported: 2014-02-04 20:31 UTC by Josh Stone
Modified: 2014-02-14 07:51 UTC (History)
3 users (show)

Fixed In Version: libdwarf-20140131-2.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1061501 (view as bug list)
Environment:
Last Closed: 2014-02-14 07:51:56 UTC


Attachments (Terms of Use)

Description Josh Stone 2014-02-04 20:31:46 UTC
Description of problem:
libdwarf is built with elfutils-libelf-devel, but it doesn't actually link libelf.so.  This means rpm doesn't know about this library dependency, and clients also have to link -lelf even when they don't use libelf directly.

Version-Release number of selected component (if applicable):
libdwarf-20140131-1.fc20.x86_64

How reproducible:
100%

Steps to Reproduce:
1. readelf -d /usr/lib64/libdwarf.so.0 | grep NEEDED
2. rpm -qR libdwarf | grep libelf
3. echo 'int main(){return 0;}' | gcc -x c - -o /dev/null -ldwarf

Actual results:
1. only NEEDED is libc.so
2. (nothing)
3. libdwarf.so: undefined reference to `elf32_getehdr' ... and many more.

Expected results:
1. There should be a NEEDED line for libelf.so.1
2. It should get an auto-require like "libelf.so.1()(64bit)" (from NEEDED).
3. With the library properly linked, clients won't need their own -lelf

Additional info:
The missing rpm dependency is unlikely to ever be an issue in practice, because rpm itself requires libelf, so it will always be present anyway.  However, I do find it bad practice that clients must use -lelf on libdwarf's behalf.  (Compare the same step-3 test with -ldw, for instance.)

Comment 1 Tom Hughes 2014-02-04 21:30:03 UTC
I think this is, at least from upstream's point of view, deliberate as it is possible to use libdwarf without libelf.

Basically if you use dwarf_object_init instead of dwarf_init of dwarf_elf_init that libelf won't be used and access to the object will be via the callbacks provided in the Dwarf_Obj_Access_Interface structure.

Of couse that doesn't mean we might not want to pull in libelf by default in Fedora.

Comment 2 Josh Stone 2014-02-04 22:16:14 UTC
It might be possible to avoid libelf if you link libdwarf.a, but when you use libdwarf.so then all symbols have to be resolved to compile and run, even the parts you won't be using.  That's why my example 3, which doesn't actually *use* libdwarf at all, must still add -lelf to link correctly.

In other words, static libdwarf work fine:
> $ echo 'int main(){return 0;}' | gcc -x c - -o /dev/null -static -ldwarf
> $ echo $?
> 0

But shared libdwarf fails:
> $ echo 'int main(){return 0;}' | gcc -x c - -o /dev/null -ldwarf
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf32_getehdr'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf_getscn'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf_begin'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf64_getshdr'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf_end'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf64_getehdr'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf_strptr'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf_getident'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf32_getshdr'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf_version'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/libdwarf.so: undefined reference to `elf_getdata'
> collect2: error: ld returned 1 exit status
> $ echo $?
> 1

It's ok again with libelf forced in:
> $ echo 'int main(){return 0;}' | gcc -x c - -o /dev/null -ldwarf -lelf
> $ echo $?
> 0

And here's the comparison I made to -ldw, which links libelf itself:
> $ echo 'int main(){return 0;}' | gcc -x c - -o /dev/null -ldw
> $ echo $?
> 0

Comment 3 Tom Hughes 2014-02-04 22:49:40 UTC
Well strictly speaking you can make it link with --allow-shlib-undefined but yes, it is enough of an edge case that it would probably make more sense to pull libelf in by default.

Comment 4 Fedora Update System 2014-02-04 23:58:09 UTC
libdwarf-20140131-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2014-1926/libdwarf-20140131-2.fc20

Comment 5 Josh Stone 2014-02-05 00:17:06 UTC
Thanks for the quick fix - it looks good to me.

(In reply to Josh Stone from comment #0)
> The missing rpm dependency is unlikely to ever be an issue in practice,
> because rpm itself requires libelf, so it will always be present anyway.

FWIW, I realized a case where this isn't true, which is multilib.  If you install libdwarf.i686 on x86_64, you may not already have elfutils-libelf.i686, so it ought to be pulled in as a dependency.  I confirmed that this didn't happen before, but it works with the new build.

Comment 6 Fedora Update System 2014-02-06 03:53:35 UTC
Package libdwarf-20140131-2.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libdwarf-20140131-2.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-1926/libdwarf-20140131-2.fc20
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2014-02-14 07:51:56 UTC
libdwarf-20140131-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


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