Bug 204259
| Summary: | can't compile trace-cmd-git on ArchLinux, unless a previous trace-cmd was already installed system-wide | ||
|---|---|---|---|
| Product: | Tools | Reporter: | GYt2bW (howaboutsynergy) |
| Component: | Trace-cmd/Kernelshark | Assignee: | Default virtual assignee for Trace-cmd and kernelshark (tools_tracecmd_kernelshark) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | blocking | CC: | howaboutsynergy, rostedt, ykaradzhov |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 5.2.2-ge9b75c60f91a | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
CMakeOutput.log
CMakeError.log from a different compilation attempt(than the prev. CMakeOutput.log file) |
||
|
Description
GYt2bW
2019-07-21 23:41:50 UTC
Created attachment 283889 [details]
CMakeError.log from a different compilation attempt(than the prev. CMakeOutput.log file)
I forgot to also attach `CMakeError.log` (didn't notice it was a different filename!)
So here's another (new)run, to generate `CMakeError.log`
> It appears as if the making of gui(aka kernelshark?) is attempted well before trace-cmd finished compiling? I'm not sure.
that guess is incorrect, because if it were true, then running these two commands would work:
1. make BUILD_TYPE=Release PYTHON_VERS=python2 prefix=/usr DESTDIR=/home/user/build/1packages/4used/trace-cmd/makepkg_pacman/trace-cmd-git/pkg/trace-cmd-git all doc
2. make BUILD_TYPE=Release PYTHON_VERS=python2 prefix=/usr DESTDIR=/home/user/build/1packages/4used/trace-cmd/makepkg_pacman/trace-cmd-git/pkg/trace-cmd-git gui
but I get the same error for the second one.
Then there must be some issue in `build/FindTraceCmd.cmake` that can be improved to fix this, maybe. I'll try to look into it, noting that I've basically no idea how these cmake/make stuff works.
Ok, two things are causing this: 1. `kernel-shark/build/FindTraceCmd.cmake` has code that says find `TRACECMD_EXECUTABLE` only if `CMAKE_BUILD_TYPE MATCHES Debug`, so this issue will always happen if trace-cmd isn't already installed system-wide AND you're trying to compile a non-debug trace-cmd (ie. `make BUILD_TYPE=Release` I guess). 2. you cannot run `make all doc gui` in one command (you have to run `make all doc` then `make gui`) or else, `kernel-shark`(aka gui) build is attempted before trace-cmd is finished, and thus the code in `kernel-shark/build/FindTraceCmd.cmake` will fail to find both `TRACECMD_EXECUTABLE` and `TRACECMD_LIBRARY` but it will find `TRACECMD_INCLUDE_DIR` (didn't check `TRACEEVENT_LIBRARY`) (so correction: Comment 2 is true(aka guess being incorrect) only because 1.(above) is also happening, otherwise, that was a good guess: that `gui` build was being attempted before the `trace-cmd`(cli?) was compiled) This 2.(above) might happen because `MAKEFLAGS="-j12"`, checking... yup, that is correct: if `MAKEFLAGS="-j1"` then step 2.(above) will not be hit. ie. in ArchLinux: `MAKEFLAGS='-j1'` in `/etc/makepkg.conf` ok, there might be a problem with step 1. in Comment 3, such that, if `TRACECMD_EXECUTABLE` is allowed to be set there, then `kernelshark` executable that's eventually installed in the system (via `pacman`, on ArchLinux) will apparently link to the absolute path of that `trace-cmd` executable from the built dir, and thus will fail to run it if that build dir is later removed, instead of using the `trace-cmd` that is now available in PATH for example. How I tested this? By commenting out the code: #if (CMAKE_BUILD_TYPE MATCHES Debug) #endif (CMAKE_BUILD_TYPE MATCHES Debug) and thus allowing it to work for `Release` too, ie. this remained: ``` #if (CMAKE_BUILD_TYPE MATCHES Debug) find_program(TRACECMD_EXECUTABLE NAMES trace-cmd PATHS $ENV{TRACE_CMD}/tracecmd/ ${CMAKE_SOURCE_DIR}/../tracecmd/ NO_DEFAULT_PATH) #endif (CMAKE_BUILD_TYPE MATCHES Debug) ``` (clearly this cannot possibly be the fix) and after install, ran `kernelshark`, pressed ctrl+r to record, the pressed Capture button three times which showed, when the build dir was removed, this: ``` trace-cmd record -e all -o /home/user/trace.dat sleep 0.1 trace-cmd record -e all -o /home/user/trace.dat sleep 0.1 trace-cmd record -e all -o /home/user/trace.dat sleep 0.1 ``` no errors, just that. But when the build dir was restored (ie. `trace-cmd` executable from build dir was made available again), then pressing Capture once yielded: ``` trace-cmd record -e all -o /home/user/trace.dat sleep 0.1 trace-cmd: No such file or directory opening '/sys/kernel/debug/tracing/tracing_on' Capture process failed: Unknown error ``` In other words, there was a `trace-cmd` that was executed this time. The other errors are to be expected because I completely disabled some required tracing CONFIG_* from my kernel. To be more precise I've disabled exactly these CONFIG_* ones, seen here: https://bugzilla.kernel.org/show_bug.cgi?id=204231#c3 Note that `/usr/bin/trace-cmd` was available this whole time that `kernelshark` was, which tells me it tried to use absolute path of `trace-cmd` from the build dir instead! To double-check: ```$ grep -Fl '/home/user/build/1packages/4used/trace-cmd/makepkg_pacman/trace-cmd-git/src/trace-cmd/tracecmd/trace-cmd' -- `pacman -Qlq trace-cmd` /usr/lib/kernelshark/libkshark-gui.so.0.9.8 ``` To add to Comment 4, to help find the exe hardcoding: ``` trace-cmd $ grep -nrIFw TRACECMD_EXECUTABLE kernel-shark/src/KsCaptureDialog.cpp:490: captureExe = TRACECMD_EXECUTABLE; kernel-shark/src/KsCmakeDef.hpp:21:#define TRACECMD_EXECUTABLE "/home/user/build/1packages/4used/trace-cmd/makepkg_pacman/trace-cmd-git/src/trace-cmd/tracecmd/trace-cmd" kernel-shark/build/deff.h.cmake:21:#cmakedefine TRACECMD_EXECUTABLE "@TRACECMD_EXECUTABLE@" kernel-shark/build/CMakeCache.txt:273:TRACECMD_EXECUTABLE:FILEPATH=/home/user/build/1packages/4used/trace-cmd/makepkg_pacman/trace-cmd-git/src/trace-cmd/tracecmd/trace-cmd ``` or with some context: ``` trace-cmd $ grep -nrIFw -C4 TRACECMD_EXECUTABLE kernel-shark/src/KsCaptureDialog.cpp-486- kernel-shark/src/KsCaptureDialog.cpp-487- if (!KsUtils::isInstalled()) kernel-shark/src/KsCaptureDialog.cpp-488- captureExe = QString(_INSTALL_PREFIX) + QString("/bin/trace-cmd"); kernel-shark/src/KsCaptureDialog.cpp-489- else kernel-shark/src/KsCaptureDialog.cpp:490: captureExe = TRACECMD_EXECUTABLE; kernel-shark/src/KsCaptureDialog.cpp-491- kernel-shark/src/KsCaptureDialog.cpp-492- _captureProc.setProgram(captureExe); kernel-shark/src/KsCaptureDialog.cpp-493- kernel-shark/src/KsCaptureDialog.cpp-494- _captureMon.connectMe(&_captureProc, &_captureCtrl); -- kernel-shark/src/KsCmakeDef.hpp-17-/** KernelShark plugins installation prefix path. */ kernel-shark/src/KsCmakeDef.hpp-18-#define KS_PLUGIN_INSTALL_PREFIX "/usr/lib/kernelshark/plugins/" kernel-shark/src/KsCmakeDef.hpp-19- kernel-shark/src/KsCmakeDef.hpp-20-/** Location of the trace-cmd executable. */ kernel-shark/src/KsCmakeDef.hpp:21:#define TRACECMD_EXECUTABLE "/home/user/build/1packages/4used/trace-cmd/makepkg_pacman/trace-cmd-git/src/trace-cmd/tracecmd/trace-cmd" kernel-shark/src/KsCmakeDef.hpp-22- kernel-shark/src/KsCmakeDef.hpp-23-/** "pkexec" executable. */ kernel-shark/src/KsCmakeDef.hpp-24-#define DO_AS_ROOT "/usr/bin/pkexec" kernel-shark/src/KsCmakeDef.hpp-25- -- kernel-shark/build/deff.h.cmake-17-/** KernelShark plugins installation prefix path. */ kernel-shark/build/deff.h.cmake-18-#cmakedefine KS_PLUGIN_INSTALL_PREFIX "@KS_PLUGIN_INSTALL_PREFIX@" kernel-shark/build/deff.h.cmake-19- kernel-shark/build/deff.h.cmake-20-/** Location of the trace-cmd executable. */ kernel-shark/build/deff.h.cmake:21:#cmakedefine TRACECMD_EXECUTABLE "@TRACECMD_EXECUTABLE@" kernel-shark/build/deff.h.cmake-22- kernel-shark/build/deff.h.cmake-23-/** "pkexec" executable. */ kernel-shark/build/deff.h.cmake-24-#cmakedefine DO_AS_ROOT "@DO_AS_ROOT@" kernel-shark/build/deff.h.cmake-25- -- kernel-shark/build/CMakeCache.txt-269-//The directory containing a CMake configuration file for Qt5Widgets. kernel-shark/build/CMakeCache.txt-270-Qt5Widgets_DIR:PATH=/usr/lib64/cmake/Qt5Widgets kernel-shark/build/CMakeCache.txt-271- kernel-shark/build/CMakeCache.txt-272-//Path to a program. kernel-shark/build/CMakeCache.txt:273:TRACECMD_EXECUTABLE:FILEPATH=/home/user/build/1packages/4used/trace-cmd/makepkg_pacman/trace-cmd-git/src/trace-cmd/tracecmd/trace-cmd kernel-shark/build/CMakeCache.txt-274- kernel-shark/build/CMakeCache.txt-275-//Path to a file. kernel-shark/build/CMakeCache.txt-276-TRACECMD_INCLUDE_DIR:PATH=/home/user/build/1packages/4used/trace-cmd/makepkg_pacman/trace-cmd-git/src/trace-cmd/include kernel-shark/build/CMakeCache.txt-277- -- ``` Hi howaboutsynergy, Thanks for the detailed report! The problem here is the following. In order to record trace data the "Record" dialog actually starts trace-cmd as a child process. However, there is a list very good arguments why unconsciously starting as root an executable from your $HOME folder is a very bad idea. This is the reason why by default CMake searches for the trace-cmd executable only in the default system paths. On the other hand, when we develop new features, we often make changes in both KernelShark and trace-cmd. In such a case it makes sense to configure KernelShark to use the modified version of trace-cmd from the build location because this way you do not have to type "sudo make install" every time when you want to test your new code. Another advantage is that this way all your modifications are kept in the build location and the already installed libraries/executable are untouched. This is why if your build type is "Debug" CMake will first search for trace-cmd from your build dir. cheers, Yordan Hi Yordan, We need to come up with a different solution to this. KernelShark must be able to be built when trace-cmd is not installed on the system. We can not expect that the code is built for where it is going to run. -- Steve Perhaps we should show the full path of the trace-cmd that is being executed by kshark-record, and not default to relative paths. Another solution is to hardcode it to whatever "prefix" is defined to, and assume that kernelshark will be installed in the same location as trace-cmd. Yordan created this patch: https://patchwork.kernel.org/patch/11055097/ I applied it and tested it this way: On my build system, I removed all trace-cmd and kernelshark code, and did this: $ mkdir /tmp/packages $ make clean $ make DESTDIR=/tmp/packages prefix=/usr install_gui $ cd /tmp/packages $ tar -cvjf /tmp/ks-package.tar.bz2 . $ scp /tmp/ks-package.tar.bz2 test-machine:/tmp on test-machine: $ su - # cd / # tar xvf /tmp/ks-package.tar.bz2 # cd ~ # which kernelshark /usr/bin/kernelshark # kernelshark And tried a Tools->Record, and all seems to be working! The patch works for me also(on ArchLinux), thanks Yordan and Steven. Fixed by commit 80940d027767d ("kernel-shark: Get the path to trace-cmd executable from _INSTALL_PREFIX")
|