ELF Dissector in kdereview

[Volker Krause]

Thanks for the feedback so far!

This has reached the two week mark, if there are no objections I'd move this 
to extragear/sdk next week.

>From the feedback everything should be addressed, apart from the following:
- blog: will be done for the release, last one on that subject is https://
volkerkrause.eu/2019/06/22/elf-dissector-aarch64-support.html
- differential view features: makes a lot of sense, not just for the ABI 
review use-case, but it's a significant amount of additional work that 
shouldn't block the review or a release.
- support for older Qt versions: I don't mind somebody adding that, but I 
don't have the bandwidth to maintain that myself. Again, IMHO not a review or 
release blocker.

Regards,
Volker

On Saturday, 28 September 2019 13:01:11 CEST Volker Krause wrote:
> Hi,
> 
> ELF Dissector has been moved to kdereview for the usual review process.
> 
> https://phabricator.kde.org/source/elf-dissector/
> 
> ELF Dissector is a static analysis tool for ELF libraries and executables,
> for doing things like inspecting forward and backward dependencies (on a
> library or symbol level), identifying load-time performance bottlenecks
> such as expensive static constructors or excessive relocations, or size
> profiling of ELF files.
> 
> ELF Dissector has been living in playground for more than 6 years because I
> was sloppy following the right process. Since it's in active use by a number
> of people, is actively maintained and remains relevant and useful I think
> it's time to finally rectify this :)
> 
> Regarding its final destination, extragear/sdk looks like the obvious
> candidate, as its such a niche tool that being part of the KDE Application
> bundle is probably hard to argue. Once KDE Applications and the "release
> service" are sufficiently decoupled, I'd of course be more than happy to
> have it covered by the automatic release process.
> 
> Regarding distribution, there is one annoying aspect, its dependency on
> semi- public binutils API for accessing the C++ symbol demangling AST. That
> works on conventional Linux distributions, but I failed to make it work as
> a Flatpak due to that.
> 
> Regarding portability, this currently only builds on ELF-based systems,
> although theoretically this could be useful on a Windows host used for
> embedded Linux development too. It's not impossible to make this work
> eventually I think, but it's probably quite some work.
> 
> Thanks,
> Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20191012/9b8515b4/attachment.sig>