Raphael Hertzog wrote: > On Wed, 21 Apr 2010, Jonathan Nieder wrote: >> If we can, dpkg-shlibdeps could be simplified a lot by using readelf >> instead of objdump. That’s something I would enjoy doing. > > In what way do you expect simplifications ?
That was sloppy of me; sorry. Even if all supported targets use ELF, I don’t think it would justify the churn. The main advantages: - readelf is tiny and works for all ELF targets. By contrast, multi-target objdump is large and its Debian package only supports the targets that were considered worth the trouble when it was last built. - ELF is lower-level and objdump does not use an abstraction that matches up well with what dpkg-shlibdeps needs. So using readelf would make it easier to verify that dpkg-shlibdeps is doing the right thing. Consider on the other hand the potential for breakage and it doesn’t sound so good. I am including what I was thinking about below for reference [1]. Sorry for the nonsense. Jonathan [1] To discover SONAME, NEEDED, RUNPATH, and RPATH, one could parse ‘eu-readelf --dynamic $file’ output. The output is very similar to that of ‘objdump --private-headers’. Explicitly using the dynamic section just has more obvious behavior (and would make it easier to switch to using libelf or similar later if that seems to be a good idea). To simulate linking in order to find shlibs files, it would be nice to find a way to use ldd (and enhance it in places where it is not helpful enough, like considering binaries for other platforms). Barring that, a first approximation which is a little stricter than the current dpkg-shlibdeps rules would be to could compare the ELF class, OS ABI version, userspace ABI version, and machine type from ‘eu-readelf --file-header $file’. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100423020343.ga12...@progeny.tock