Re: (not) simplifying dpkg-shlibdeps with readelf
Hello, 2010/4/28 Russ Allbery r...@debian.org: [...] I'm not sure what you mean by flat binaries here. I meant http://www.beyondlogic.org/uClinux/bflt.htm [...] I see no reason why embedded platforms can't use ELF. ELF is very common in the embedded world even entirely apart from Linux. Sometimes ELF is not best for XIP (eXecute In Place) and other formats do better. I wonder if Debian will be able to cope with those sometime. What about mingw32 targets? (I have not worked with) Some people build Debian packages for such target. Kind regards, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- 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/o2kdd0a3d701004290224w13a7fb25uc08cd03dc6b64...@mail.gmail.com
Re: (not) simplifying dpkg-shlibdeps with readelf
Hi, On Thu, Apr 29, 2010 at 11:24:35AM +0200, Hector Oron wrote: I see no reason why embedded platforms can't use ELF. ELF is very common in the embedded world even entirely apart from Linux. There is some effort to move from bFLT to something called FDPIC ELF, which is basically ELF with runtime relocation of binaries and libraries, and an ABI extension that allows per-process instantiation of writeable segments. The difficulty there is that this format is severely underdocumented, and no C library supports it out of the box in their dynamic linker. I think in the long run everything will be ELF. Sometimes ELF is not best for XIP (eXecute In Place) and other formats do better. I wonder if Debian will be able to cope with those sometime. XIP is a subset of the per-process instantiation problem. What about mingw32 targets? (I have not worked with) Some people build Debian packages for such target. The current objdump based implementation is already dependent on ELF, as only ELF uses the string NEEDED. Simon -- 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/20100429123803.gb7...@honey.hogyros.de
Re: (not) simplifying dpkg-shlibdeps with readelf
Hector Oron hector.o...@gmail.com writes: 2010/4/28 Russ Allbery r...@debian.org: [...] I'm not sure what you mean by flat binaries here. I meant http://www.beyondlogic.org/uClinux/bflt.htm Ah, thank you. I hadn't known about that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87mxwmqflu@windlord.stanford.edu
Re: (not) simplifying dpkg-shlibdeps with readelf
Hello Russ, 2010/4/27 Russ Allbery r...@debian.org: I have a hard time imagining Debian ever supporting non-ELF targets. We'd need to maintain a completely separate libc, for instance, since I'm fairly sure glibc is ELF only. uClibc is on the archive (not usable for runtime), it was also added to dpkg as a new architecture, maybe someday we'll have a uClibc (w/ MMU and w/o MMU). We might need to support flat binaries for that. There are also some teams and individuals which have the desire to work on mobile world having Debian on them, for such purposes and maybe not officially, there is space for a bionic libc or some others that might be suitable for such purposes. I do not want to interfere on the decission of using readelf, but at least take into account those points before doing any change which might be hard to revert later on. Kind regards, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- 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/h2tdd0a3d701004280404u265efd3ai4d61b25d91589...@mail.gmail.com
Re: (not) simplifying dpkg-shlibdeps with readelf
Hi, 2010/4/23 Jonathan Nieder jrnie...@gmail.com: 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. Excuse my ignorance, but I have a question regarding non-ELF targets, Are you sure Debian is tight to *only* ELF target support? Aren't we going to support non-ELF targets anytime? On the other hand I can see the benefit on readelf compared to objdump. Best regards, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- 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/h2qdd0a3d701004270105o690bb3bak133de7a208957...@mail.gmail.com
Re: (not) simplifying dpkg-shlibdeps with readelf
Hector Oron hector.o...@gmail.com writes: Excuse my ignorance, but I have a question regarding non-ELF targets, Are you sure Debian is tight to *only* ELF target support? Aren't we going to support non-ELF targets anytime? On the other hand I can see the benefit on readelf compared to objdump. I have a hard time imagining Debian ever supporting non-ELF targets. We'd need to maintain a completely separate libc, for instance, since I'm fairly sure glibc is ELF only. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87hbmwsipe@windlord.stanford.edu
Re: (not) simplifying dpkg-shlibdeps with readelf
On Thu, Apr 22, 2010, Jonathan Nieder wrote: - 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. I guess you mean binutils-multiarch here; I submitted a patch in Debian #578365 to use a cross-objdump when cross-building. I expect objdump or cross-objdump should support the binaries which you're about to ship in a .deb. The only other case I can think of is when a package's build calls a non-default (cross-)compiler to generate a specific file, e.g. a firmware, in which case it might not be ELF at all. [1] To discover SONAME, NEEDED, RUNPATH, and RPATH, one could parse ‘eu-readelf --dynamic $file’ output. You might want to consider symbols as well as to have dpkg-shlibdeps and dpkg-gensymbols rely on the same underlying tool. -- Loïc Minier -- 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/20100426115011.ga14...@bee.dooz.org
Re: (not) simplifying dpkg-shlibdeps with readelf
Loïc Minier l...@dooz.org writes: On Thu, Apr 22, 2010, Jonathan Nieder wrote: - 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. I guess you mean binutils-multiarch here; I submitted a patch in Debian #578365 to use a cross-objdump when cross-building. I expect objdump or cross-objdump should support the binaries which you're about to ship in a .deb. The only other case I can think of is when a package's build calls a non-default (cross-)compiler to generate a specific file, e.g. a firmware, in which case it might not be ELF at all. For Lintian purposes, we've also found readelf to just generally be a much nicer tool. We have a lot of logic right now to patch around various problems with objdump, such as inferior error reporting, and I hope to eventually replace all that code with readelf, which always works the way that I expect it to work. This isn't a very persuasive argument for changing code that already works, of course, but if you do extensive work around the code that uses objdump, you may want to take a look at readelf. It's quite nice. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87sk6h3iqd@windlord.stanford.edu
