Bug 1061432

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.

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

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.

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

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.

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).

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.