ELF Dissector in kdereview

[Jonathan Riddell]

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>

I couldn't compile it, I get:

[  2%] Building CXX object
src/lib/CMakeFiles/libelfdissector.dir/elf/elfdynamicentry.cpp.o
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
In file included from /usr/include/c++/7/bits/stl_algo.h:59:0,
                 from /usr/include/c++/7/algorithm:62,
                 from
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:142,
                 from
/usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:45,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QMetaType:1,
                 from
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfsection.h:23,
                 from
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfarraysection.h:21,
                 from
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfdynamicsection.h:21,
                 from
/home/jr/src/elf-dissector/elf-dissector/src/lib/elf/elfdynamicentry.cpp:19:
/usr/include/c++/7/cstdlib:75:15: fatal error: stdlib.h: No such file or
directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.

but I do have the file /usr/include/c++/7/stdlib.h

Jonathan



On Sat, 28 Sep 2019 at 12:03, Volker Krause <vkrause at kde.org> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20191001/35cb6c43/attachment.htm>