<div dir="ltr"><div>The file src/3rdparty/treemap/treemap.cpp is GPL while the rest of the application is LGPL. This makes the whole application copyable under only the terms of the GPL. It would be good to have COPYING moved to COPYING.LIB and a GPL text put in COPYING. src/ui/org.kde.elf-dissector.appdata.xml should also be changed to be <project_license>GPL-2.0-or-later</project_license></div><div><br></div><div>I couldn't compile it, I get:<br></div><div><br></div><div>[ 2%] Building CXX object src/lib/CMakeFiles/libelfdissector.dir/elf/elfdynamicentry.cpp.o<br>cd /home/jr/src/elf-dissector/elf-dissector/build/src/lib && /usr/bin/c++ -DQT_CORE_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/jr/src/elf-dissector/elf-dissector/build/src/lib -I/home/jr/src/elf-dissector/elf-dissector/src/lib -I/home/jr/src/elf-dissector/elf-dissector/build/src/lib/libelfdissector_autogen/include -I/home/jr/src/elf-dissector/elf-dissector/src -I/home/jr/src/elf-dissector/elf-dissector/src/3rdparty -I/home/jr/src/elf-dissector/elf-dissector/build -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem /usr/include/libiberty -isystem /usr/include/libdwarf -isystem /usr/include/capstone/.. -std=c++0x -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -g -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -std=gnu++14 -o CMakeFiles/libelfdissector.dir/elf/elfdynamicentry.cpp.o -c /home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfdynamicentry.cpp<br>In file included from /usr/include/c++/7/bits/stl_algo.h:59:0,<br> from /usr/include/c++/7/algorithm:62,<br> from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:142,<br> from /usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:45,<br> from /usr/include/x86_64-linux-gnu/qt5/QtCore/QMetaType:1,<br> from /home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfsection.h:23,<br> from /home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfarraysection.h:21,<br> from /home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfdynamicsection.h:21,<br> from /home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfdynamicentry.cpp:19:<br>/usr/include/c++/7/cstdlib:75:15: fatal error: stdlib.h: No such file or directory<br> #include_next <stdlib.h><br> ^~~~~~~~~~<br>compilation terminated.</div><div><br></div><div>but I do have the file /usr/include/c++/7/stdlib.h</div><div><br></div><div>Jonathan</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 28 Sep 2019 at 12:03, 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">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, for <br>
doing things like inspecting forward and backward dependencies (on a library <br>
or symbol level), identifying load-time performance bottlenecks such as <br>
expensive static constructors or excessive relocations, or size profiling of <br>
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 it's <br>
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 have <br>
it covered by the automatic release process.<br>
<br>
Regarding distribution, there is one annoying aspect, its dependency on semi-<br>
public binutils API for accessing the C++ symbol demangling AST. That works on <br>
conventional Linux distributions, but I failed to make it work as a Flatpak <br>
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</blockquote></div>