> 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 <j...@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 <vkra...@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 > >
