Jenkins compiler warnings plugin not showing C or C++ source code - jenkins

My build script includes
make clean
make all
make invokes gcc:
gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
my post-build step is to, "scan for compiler warnings" and I chose the parser for GNU C Compiler 4 (gcc).
Is that enough? Did I miss anything?
My console log shows
[WARNINGS] Parsing warnings in console log with parser GNU C Compiler 4 (gcc)
[WARNINGS] Computing warning deltas based on reference build #72
When I click on the compiler warnings chart and drill down to a single source file, I get
Copying the source file '../software_under_test/maths.c' from the workspace to the build folder '8410a4f3.tmp' on the Jenkins master failed.
02 Seems that the path is relative, however an absolute path is required when copying the sources.
03 Is the file 'maths.c' contained more than once in your workspace?
04 Is the file '../software_under_test/maths.c' a valid filename?
05 If you are building on a slave: please check if the file is accessible under '$JENKINS_HOME/[job-name]/../software_under_test/maths.c'
06 If you are building on the master: please check if the file is accessible under '$JENKINS_HOME/[job-name]/workspace/../software_under_test/maths.c'
07 java.io.IOException: Failed to copy ../software_under_test/maths.c to /home/mawg/.jenkins/jobs/plain_C_project/builds/73/workspace-files/8410a4f3.tmp
08 at hudson.FilePath.copyTo(FilePath.java:1991)
09 at hudson.plugins.analysis.util.Files.copyFilesWithAnnotationsToBuildFolder(Files.java:80)
10 at hudson.plugins.analysis.core.HealthAwareRecorder.copyFilesWithAnnotationsToBuildFolder(HealthAwareRecorder.java:312)
11 at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:89)
12 at hudson.plugins.analysis.core.HealthAwareRecorder.perform(HealthAwareRecorder.java:259)
13 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:75)
14 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
15 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
16 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:726)
17 at hudson.model.Build$BuildExecution.post2(Build.java:185)
18 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671)
19 at hudson.model.Run.execute(Run.java:1766)
20 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
21 at hudson.model.ResourceController.execute(ResourceController.java:98)
22 at hudson.model.Executor.run(Executor.java:408)
23 Caused by: java.io.FileNotFoundException: ../software_under_test/maths.c (No such file or directory)
24 at java.io.FileInputStream.open(Native Method)
25 at java.io.FileInputStream.<init>(FileInputStream.java:146)
26 at hudson.FilePath$41.invoke(FilePath.java:2017)
27 at hudson.FilePath$41.invoke(FilePath.java:2012)
28 at hudson.FilePath.act(FilePath.java:991)
29 at hudson.FilePath.act(FilePath.java:969)
30 at hudson.FilePath.copyTo(FilePath.java:2012)
31 at hudson.FilePath.copyTo(FilePath.java:1986)
32 ... 14 more
What am I doing wrong?
This page says that the code is looking for the string "Entering directory" in the build output and the code verifies this.
I tweaked my make step to output that by adding the --print-directory to the make command and got
+ make all --print-directory
make: Entering directory `/home/mawg/workspace/unit_test_C_code_example_project/Debug'
Building file: ../test_scripts/test_maths.c
Invoking: GCC C Compiler
gcc -DUNIT_TEST -I"/home/mawg/workspace/unit_test_C_code_example_project/mocks" -I"/home/mawg/workspace/unit_test_C_code_example_project/software_under_test" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"test_scripts/test_maths.d" -MT"test_scripts/test_maths.d" -o "test_scripts/test_maths.o" "../test_scripts/test_maths.c"
Finished building: ../test_scripts/test_maths.c
etc, but that did not help.
So, can anyone tell me how to configure things so that I an drill down into the source code from the Jenkins compiler warnings plugin?

This was one of the first results when I had this problem, but I have since found that as of at least 2018-07 there is an advanced setting to “Resolve relative paths” (not sure when this was added), but this solved the same problem for me
Update:
After adding the Scan for compiler warnings Post Build action in Jenkins, there will be an Advanced button.
After clicking Advanced a list of options appears. Some way down this list there is a section titled Resolve relative paths, clicking on this solved my problem.
This was in the Warning plugin version 4.66

Solved!
I had the same Problem and got rid of it after following changes:
I set the at the Source Code Management-->Local module Directory
a Period following the checkout Folder of the Project i.e. "./project1"
I didnt have the "./" before.
I added also to the make command the Option --print-directory.
Now it works as expected!

Ok, solved!
The problem was that the makefile generated by Eclipse contain ed a relative path. Relative to the makefile directory that it, but the Jenkins compiler warning plugin was treating it as relative to the Jenkins workspace.
The solution is to edit the makeilfe. Do it once for a manually created makefile. If you use Eclipse it constantly regenerates the makefiles, so the trick is to edit the Jenkins shell script to change the makefile on the fly, immediately prior to building.
Note that I only changed the makefile for the Software Under Test directory. I am not interested in compiler warnings in Google Test, etc
So, now my Jenkins shell script starts
cd /home/mawg/workspace/unit_test_C_code_example_project/Debug
# Tweak the makefile to use an absolute path to the Software Under Test.
# If we use a relative path then the Jenkins comiler wanrings plugin
# cannot find the source code to display it, so that we can drill down
# into it and see the compiler warnings in situ.
sed 's|\.\./software_under_test/maths.c|/home/mawg/workspace/unit_test_C_code_example_project/software_under_test/maths.c|g' /home/mawg/workspace/unit_test_C_code_example_project/Debug/software_under_test/subdir.mk > /home/mawg/workspace/unit_test_C_code_example_project/Debug/software_under_test/subdir.mk.absolute
rm software_under_test/subdir.mk
mv software_under_test/subdir.mk.absolute software_under_test/subdir.mk
make clean
# The --print-directory option is required for the compiler warning plugin
make all --print-directory

Related

Yocto Add own Header and Lib file's to sdk

i want to add .h and .lib files to a own created recipe to the sdk.
I use cmake to build my lib's, with the sdk i can build it.
My recipe name is served. (i want to add the served https://github.com/meltwater/served as a own recipe).
in my served_0.1.bb File i add following:
BBCLASSEXTEND = "native nativesdk"
RDEPENDS_${PN} += "nativesdk-served"
in the layer.conf i add:
TOOLCHAIN_TARGET_TASK_append = " served "
When i start to create my sdk with
bitbake core-image-base -c populate_sdk
ERROR: core-image-base-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/3.2.4/sysroots/cortexa72-poky-linux/etc/dnf/dnf.conf --setopt=reposdir=/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/3.2.4/sysroots/cortexa72-poky-linux/etc/yum.repos.d --installroot=/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/3.2.4/sysroots/cortexa72-poky-linux --setopt=logdir=/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/temp --repofrompath=oe-repo,/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/oe-sdk-repo --nogpgcheck install packagegroup-base-extended packagegroup-core-boot packagegroup-core-standalone-sdk-target psplash-raspberrypi run-postinsts served target-sdk-provides-dummy' returned 1:
DNF version: 4.2.23
cachedir: /home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/3.2.4/sysroots/cortexa72-poky-linux/var/cache/dnf
Added oe-repo repo from /home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/oe-sdk-repo
User-Agent: falling back to 'libdnf': could not detect OS or basearch
repo: using cache for: oe-repo
oe-repo: using metadata from Sun 06 Jun 2021 03:50:26 PM UTC.
Last metadata expiration check: 0:00:01 ago on Sun 06 Jun 2021 03:50:26 PM UTC.
--> Starting dependency resolution
--> Finished dependency resolution
Error:
Problem: conflicting requests
nothing provides nativesdk-served needed by served-1.0+git0+2eb36b83fa-r0.cortexa72 (try to add '--skip-broken' to
skip uninstallable packages)
ERROR: Logfile of failure stored in:
/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/temp/log.do_populate_sdk.27092
ERROR: Task
(/home/yocto/videoMon/meta/recipes-core/images/core-image-base.bb:do_populate_sdk)
failed with exit code '1'
Have anyone an idea?
Bests
Assuming that you have a recipe for served which compiles without errors.
The step to add served .h and lib files to sdk is to add below line to local.conf
TOOLCHAIN_TARGET_TASK_append = " served "
And then run command
bitbake core-image-base -c populate_sdk
The lines below in your served recipe are causing errors and are not needed for SDK generation. Please remove them and try building your image again.
BBCLASSEXTEND = "native nativesdk"
RDEPENDS_${PN} += "nativesdk-served"

Trouble building Drake with Bazel

I have been attempting to build Drake from source with Bazel on Ubuntu 18.04 but the following error occurs when I run
bazel build ...
from the Drake root directory:
ERROR: /home/username/dir/drake/bindings/pydrake/BUILD.bazel:56:37: Action bindings/pydrake/documentation_pybind.h failed (Exit 1) mkdoc failed: error executing command bazel-out/host/bin/tools/workspace/pybind11/mkdoc -DDRAKE_COMMON_SYMBOLIC_DETAIL_HEADER -DEIGEN_MPL2_ONLY -DHAVE_CSTDDEF '-DFMT_HEADER_ONLY=1' '-DFMT_NO_FMT_STRING_ALIAS=1' -DHAVE_SPDLOG ... (remaining 1096 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
external/eigen/include/_usr_include_eigen3/Eigen/Core:66:12: fatal error: 'new' file not found
Traceback (most recent call last):
File "/home/username/.cache/bazel/_bazel_username/6e98757561df7a931d098ab985a3e673/sandbox/linux-sandbox/1371/execroot/drake/bazel-out/host/bin/tools/workspace/pybind11/mkdoc.runfiles/drake/tools/workspace/pybind11/mkdoc.py", line 841, in <module>
main()
File "/home/username/.cache/bazel/_bazel_username/6e98757561df7a931d098ab985a3e673/sandbox/linux-sandbox/1371/execroot/drake/bazel-out/host/bin/tools/workspace/pybind11/mkdoc.runfiles/drake/tools/workspace/pybind11/mkdoc.py", line 805, in main
severities.count(cindex.Diagnostic.Fatal)))
RuntimeError: Parsing headers using the clang library failed with 0 error(s) and 1 fatal error(s)
----------------
Note: The failure of target //tools/workspace/pybind11:mkdoc (with exit code 1) may have been caused by the fact that it is running under Python 3 instead of Python 2. Examine the error to determine if that appears to be the problem. Since this target is built in the host configuration, the only way to change its version is to set --host_force_python=PY2, which affects the entire build.
If this error started occurring in Bazel 0.27 and later, it may be because the Python toolchain now enforces that targets analyzed as PY2 and PY3 run under a Python 2 and Python 3 interpreter, respectively. See https://github.com/bazelbuild/bazel/issues/7899 for more information.
----------------
INFO: Elapsed time: 2345.311s, Critical Path: 321.76s
INFO: 1378 processes: 1378 linux-sandbox.
FAILED: Build did NOT complete successfully
Prior to building, I ran:
sudo ./setup/ubuntu/install_prereqs.sh
as mentioned in the installation instructions.
I had also set the environment variables for the c and c++ compilers to $CC=/usr/bin/gcc and $CXX=/usr/bin/gcc because I was suspicious of compiler issues being the problem. To compare against this, I also tried to build with $CC=/usr/bin/clang-9 and $CXX=/usr/bin/clang++-9, with a different resulting error:
ERROR: /home/username/dir/drake/systems/framework/BUILD.bazel:213:17: C++ compilation of rule '//systems/framework:cache_and_dependency_tracker' failed (Exit 1) clang-9 failed: error executing command /usr/bin/clang-9 -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 77 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
In file included from systems/framework/cache.cc:1:
bazel-out/k8-opt/bin/systems/framework/_virtual_includes/cache_and_dependency_tracker/drake/systems/framework/cache.h:7:10: fatal error: 'cstdint' file not found
#include <cstdint>
^~~~~~~~~
I suspect that there is some issue with the include paths that are being used during build since both compilers were unable to find standard files, however I am unsure of what to try next or how to fix this. Any suggestions or advice would be greatly appreciated!
This seems to be the same problem that I encountered. My Question is here Encounter "RuntimeError: The operating system's C++ standard library is not installed correctly" when build drake from source using bazel and I solve my problem following #jwnimmer-tri's answer.
It turns out that Clang is looking for GCC's standard library and it seems that it looks for GCC with higher version (not sure). I guess the problem is that you have gcc-8 installed but not g++-8, so after you install g++-8 you can fix the issue. Another possible way to solve your problem is to follow #jwnimmer-tri's answer in my question to remove gcc-8 completely.

ant debug failed to include gdb.setup in the apk file

I've been building (from a mac terminal) this native application successfully for a long time but today I've run across an error I can't seem to pin down. After tiring from all the javac warnings I upgraded to a newer version of ant. I'm not sure it is related but the timing is suspect. I can still build, deploy, and run my application but now I can no longer use ndk-gdb to debug the native part of the application. It appears on inspection that the gdb.setup file is not getting added to the debug apk.
here is the build sequence, abbreviated output, and information. I'm looking for suggestions on how to resolve the issue.
I've done a full clean on both NDK and ant builds
The android NDK version and android SDK versions are all up to date.
I use the built in ndk-bundle that gets loaded with the android studio sdk tools.
The devices we develop on are not rooted and is not an option.
hsmith$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
hsmith$ $ANT_HOME
-bash: /Users/hsmith/dk/ant/apache-ant-1.9.6: is a directory
hsmith$ ndk-build -j4 NDK_DEBUG=1
[armebi-v7a] Gdbserver : [arm-linux-androideabi-4.8] libs//gdbserver
[armebi-v7a] Gdbsetup : libs//gdb.setup
[armebi-v7a] Install : lib1.so => libs/armebi-v7a/lib1.so
[armebi-v7a] Install : lib2.so => libs/armebi-v7a/lib2.so
[armebi-v7a] Install : lib3.so => libs/armebi-v7a/lib3.so
hsmith$ ant debug
…
-package:
[apkbuilder] Found modified input file
[apkbuilder] Creating -debug-unaligned.apk and signing it with a debug key...
-post-package:
-do-debug:
[zipalign] Running zip align on final apk...
[echo] Debug Package: /Users/hsmith/packageFolder/bin/<package>-debug.apk
[propertyfile] Updating property file: /Users/hsmith/packageFolder/bin/build.prop
[propertyfile] Updating property file: /Users/hsmith/packageFolder/bin/build.prop
[propertyfile] Updating property file: /Users/hsmith/packageFolder/bin/build.prop
[propertyfile] Updating property file: /Users/hsmith/packageFolder/bin/build.prop
-post-build:
debug:
BUILD SUCCESSFUL
hsmith$ adb install -r ~/packageFolder/bin/-debug.apk
hsmith$ ndk-gdb adb --start
ERROR: Package is not debuggable ! You can fix that in two ways:
Rebuilt with the NDK_DEBUG=1 option when calling 'ndk-build'.
Modify your manifest to set android:debuggable attribute to "true",
then rebuild normally.
After one of these, re-install to the device!
I unzipped the apk file to find
unziped apk file/lib/target/
hsmith$ ls -la
total 48264
drwxr-xr-x 12 hsmith staff 408 Aug 25 14:50 .
drwxr-xr-x 5 hsmith staff 170 Aug 25 14:50 ..
-rwxr-xr-x 1 hsmith staff 409940 Jun 3 11:47 gdbserver
-rwxr-xr-x 1 hsmith staff 33920 Aug 25 14:44 lib1.so
-rwxr-xr-x 1 hsmith staff 165092 Aug 25 14:44 lib2.so
-rwxr-xr-x 1 hsmith staff 1614028 Aug 25 14:44 lib3.so
note there is no gdb.setup file
I don't use debuggable=true in the manifest because it isn't needed anymore however including it has no affect on the result.
UPDATE: https://code.google.com/p/android/issues/detail?id=183455
This is exactly the problem I'm having. if you copy the target gdb.setup file from the target directory to the ./lib directory you can get ndk-gdb to work; The COMPAT_ABI variable in ndk-gdb isn't being set correctly and sending the script into a spin. I hope they fix this one soon. almost three days wasted on a broken tool chain.
UPDATE: https://code.google.com/p/android/issues/detail?id=183455 This is exactly the problem I'm having. if you copy the target gdb.setup file from the target directory to the ./lib directory you can get ndk-gdb to work; The COMPAT_ABI variable in ndk-gdb isn't being set correctly and sending the script into a spin. I hope they fix this one soon. almost three days wasted on a broken tool chain.

CMake Generated Eclipse CDT Project Does Not Have System Includes

My problem is similar with this: http://www.eclipse.org/forums/index.php/m/649323/
I created a cmake project, and used
cmake .. -G "Eclipse CDT4 - Unix Makefiles"
to create a Eclipse CDT4 project.
But in the CDT IDE, the standard include paths are not listed, and all STL or system build-in header files include directives are marked as "cannot be resolved", so the "Open Declaration" or other a lot of operation cannot be done.
However, I could compile it without any problems.
My co-worker also has a cmake project, but it's very complicated. The CDT project generated from his cmake project DOES have the system includes. But his cmake is way too complicated, and he told me that he didn't do anything special to include the system paths.
Can anyone help me out? Thanks.
My Main CMakeLists.txt:
CMake_Minimum_Required(VERSION 2.8)
# Some settings
Set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS ON)
CMake_Policy(SET CMP0015 NEW)
#Include(CMakeProcedures.cmake)
#CheckEnvironment()
# Set the compiler and its version if needed
# Create the project
Project(MyProjectName CXX)
# Set the compiler
Set(CMAKE_CXX_COMPILER /usr/bin/g++)
# Detect whether we are in-source
If (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
Message(FATAL_ERROR "In-source building is not allowed! Please create a 'build' folder and then do 'cd build; cmake ..'")
EndIf()
# Set the output dirs
Set(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin)
Set(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
# Add source subdirs to the build
Add_Subdirectory(src)
# Add_Subdirectory(test EXCLUDE_FROM_ALL)
Peter
One workaround is to manually add these to the CDT IDE:
/usr/include/c++/4.5
/usr/include/c++/4.5/backward
/usr/include/c++/4.5/i686-linux-gnu
/usr/include/i386-linux-gnu
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include-fixed
/usr/local/include
But it's not the solution.
I finally figured out that this line is causing the problem:
Project(MyProjectName CXX)
If we remove the optional paramter CXX, life is good.
Can anyone tell me why?
Peter

Crypto++ linker error using ANT

I am trying to reverse engineer a previous employee's build process for some custom software he wrote for us. I've seen to get everything to compile okay, but I get an error in the linking process that points to a problem with crypto++. Any clues?
compile.util:
compile:
[echo] Compiling: util
[cc] Starting dependency analysis for 55 files.
[cc] 55 files are up to date.
[cc] 0 files to be recompiled from dependency analysis.
[cc] 0 total files to be compiled.
link.util:
link:
[echo] Linking shared library: libutil
[cc] 0 total files to be compiled.
[cc] Starting link
[cc] /usr/bin/ld: /home/john/softwarename/thirdparty/crypto/5.6.1_64/libcryptopp.a(cryptlib.o): relocation R_X86_64_32 against `CryptoPP::DEFAULT_CHANNEL' can not be used when making a shared object; recompile with -fPIC
[cc] /home/john/softwarename/thirdparty/crypto/5.6.1_64/libcryptopp.a: could not read symbols: Bad value
[cc] collect2: ld returned 1 exit status
BUILD FAILED
/home/john/softwarename/build/build.xml:167: Following error occured while executing this line
/home/john/softwarename/build/link.xml:27: gcc failed with return code 1
Os is Fedora 11
Every object file you link into a shared library must be position independent, meaning the loader can move it wherever it wants in memory and it will still work. Your crypto library was not compiled that way, hence the admonition to recompile it with -fPIC added to your compile flags. Alternately, you can make libutil a static library instead of a shared one. Without more details on your build files, I can't provide more details on how to do that or which one to choose.

Resources