ELF Dissector in kdereview

[Elv1313 .]

> I couldn't compile it, I get

The hack for this is to replace all `-isystem` by `-I` in
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/ using `sed -i`. However, right, it
didn't compile for me either.

On Tue, 1 Oct 2019 at 05:07, Jonathan Riddell <jr at jriddell.org> wrote:

> 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/cee31a9c/attachment.htm>