<div dir="ltr"><div>I'm getting a build failure for this on 32-bit arm</div><div><br></div><div><a href="https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissector_bin_armhf/7/console">https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissector_bin_armhf/7/console</a></div><div><pre class="gmail-console-output">disassembler.cpp:149:34: error: ‘print_insn_little_arm’ was not declared in this scope<br><br></pre>Is it expected to build on this architecture?  It builds fine on 64 bit arm.<br><br><br>Jonathan<pre class="gmail-console-output"><br><br><br></pre></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 27 Oct 2019 at 09:27, Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks again for the feedback, this has now been moved to extragear/sdk.<br>
<br>
On Saturday, 28 September 2019 13:01:11 CET Volker Krause wrote:<br>
> Hi,<br>
> <br>
> ELF Dissector has been moved to kdereview for the usual review process.<br>
> <br>
> <a href="https://phabricator.kde.org/source/elf-dissector/" rel="noreferrer" target="_blank">https://phabricator.kde.org/source/elf-dissector/</a><br>
> <br>
> ELF Dissector is a static analysis tool for ELF libraries and executables,<br>
> for doing things like inspecting forward and backward dependencies (on a<br>
> library or symbol level), identifying load-time performance bottlenecks<br>
> such as expensive static constructors or excessive relocations, or size<br>
> profiling of ELF files.<br>
> <br>
> ELF Dissector has been living in playground for more than 6 years because I<br>
> was sloppy following the right process. Since it's in active use by a number<br>
> of people, is actively maintained and remains relevant and useful I think<br>
> it's time to finally rectify this :)<br>
> <br>
> Regarding its final destination, extragear/sdk looks like the obvious<br>
> candidate, as its such a niche tool that being part of the KDE Application<br>
> bundle is probably hard to argue. Once KDE Applications and the "release<br>
> service" are sufficiently decoupled, I'd of course be more than happy to<br>
> have it covered by the automatic release process.<br>
> <br>
> Regarding distribution, there is one annoying aspect, its dependency on<br>
> semi- public binutils API for accessing the C++ symbol demangling AST. That<br>
> works on conventional Linux distributions, but I failed to make it work as<br>
> a Flatpak due to that.<br>
> <br>
> Regarding portability, this currently only builds on ELF-based systems,<br>
> although theoretically this could be useful on a Windows host used for<br>
> embedded Linux development too. It's not impossible to make this work<br>
> eventually I think, but it's probably quite some work.<br>
> <br>
> Thanks,<br>
> Volker<br>
<br>
</blockquote></div>