I am trying to run coverage on my project, after updating to Ubuntu 16.04.
I get
Deleted 665 files
Writing data to coverage.info.cleaned
lcov: ERROR: cannot write to coverage.info.cleaned!
CMakeFiles/coverage.dir/build.make:57: recipe for target 'CMakeFiles/coverage' failed
make[3]: *** [CMakeFiles/coverage] Error 13
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/coverage.dir/all' failed
make[2]: *** [CMakeFiles/coverage.dir/all] Error 2
CMakeFiles/Makefile2:74: recipe for target 'CMakeFiles/coverage.dir/rule' failed
make[1]: *** [CMakeFiles/coverage.dir/rule] Error 2
Makefile:129: recipe for target 'coverage' failed
make: *** [coverage] Error 2
enter code here
Before the update I had no problem running the coverage
Does it help if you use absolute paths instead of relative paths when passing files to lcov?
I ran into a similiar problem where lcov also failed to write the file.
Not sure if it is a bug in lcov, but the problem was that it got confused with relative paths:
lcov -a test_fast_cxxtest_gcov__base.info -a test_fast_cxxtest_gcov__test.info \
-o test_fast_cxxtest_gcov__total.info
Combining tracefiles.
Reading tracefile test_fast_cxxtest_gcov__base.info
Reading tracefile test_fast_cxxtest_gcov__test.info
lcov: WARNING: function data mismatch at /home/phil/ghost/constants.h:1862
Writing data to test_fast_cxxtest_gcov__total.info
lcov: ERROR: cannot write to test_fast_cxxtest_gcov__total.info!
Running it with strace revealed that it executes chdir("/") on several locations, which changes the working directory to /. That explains why it cannot write the file.
One workaround is to use absolute paths. For instance, if you are using GNU make, you can use the abspath command:
lcov -a $(abspath test_fast_cxxtest_gcov__base.info) \
-a $(abspath test_fast_cxxtest_gcov__test.info) \
-o $(abspath test_fast_cxxtest_gcov__total.info)
After that change, it was finally able to write the file.
(Other options like trying to set the directories using the --base-directory or --directory option did not have an effect, as far as I saw.
The version of lcov that I tested with is 1.12.)
The problem is not limited to Ubuntu, as I ran into it on Arch Linux. It could be a regression introduced in 1.12, however, so I reported it (see issue #77630).
Update: Lcov is not part of GCC, so my original bug report was closed, but I got an answer from the Lcov mailing list. The problem is already fixed in commit 632c25. Users of Arch Linux based distros can try the latest snapshot with aur/lcov-git.
Related
I am trying to install OpenCV3.1 on my Ubuntu 16.04 for development in QT5. Sadly, building it from source always errors out due to undefined references (see below).
I used the following:
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_TBB=ON -D WITH_V4L=ON -D WITH_FFMPEG=ON -D WITH_OPENGL=ON -D BUILD_TIFF=ON -D WITH_VTK=ON..
And it works fine. But building it always produces this error
../../lib/libopencv_viz.so.3.1.0: undefined reference to `vtkSTLReader::New()'
../../lib/libopencv_viz.so.3.1.0: undefined reference to `vtkOBJReader::New()'
collect2: error: ld returned 1 exit status
modules/viz/CMakeFiles/opencv_test_viz.dir/build.make:232: recipe for target 'bin/opencv_test_viz' failed
make[2]: *** [bin/opencv_test_viz] Error 1
CMakeFiles/Makefile2:3358: recipe for target 'modules/viz/CMakeFiles/opencv_test_viz.dir/all' failed
make[1]: *** [modules/viz/CMakeFiles/opencv_test_viz.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Of course I googled and tried everything I found. Tried several different cmake flags (or rather, without any), tried reinstalling libvtk5-dev and also tried libvtk6-dev and even build vtk7.1 from source, since I am assuming something is missing from there.
I also tried adding the opencv_contrib via
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_TBB=ON -D WITH_V4L=ON -D WITH_FFMPEG=ON -D WITH_OPENGL=ON -D BUILD_TIFF=ON -D WITH_VTK=ON -D BUILD_EXAMPLES=ON -D OPENCV_EXTRA_MODULES_PATH=/home/user/opencv/opencv-3.1.0/opencv_contrib/modules ..
But that already produced the following error
CMake Error at opencv_contrib/modules/text/CMakeLists.txt:22 (ocv_add_testdata): `Unknown CMake command "ocv_add_testdata".
Also please note that I did upgrade/update all the packages that are listed here and here
So basically after two days randomly trying all the possible solutions I could find via google, I am now asking here.
Hopefully someone knows how to fix this, thank you!
Edit: I only get these problems with OpenCV3.1. I do have a working OpenCV 2.4.13
Same happend with me. It was working and suddenly I got the same error. I re-pulled OpenCV 3.1 and it worked again.
It seems that the guys updated something both in Extra Modules and in OpenCV and you have just pull the extra modules.
For the second part, it looks like someone messed up the opencv_contrib/modules/text/CMakeLists.txt
Just edit this file and remove the lines at the end:
ocv_add_testdata(samples/ contrib/text
FILES_MATCHING PATTERN "*.xml" PATTERN "*.xml.gz" REGEX "scenetext[0-9]+.jpg"
COMPONENT "tests"
)
just switch opencv_contrib repository to 3.1.0 tag after clone.
git checkout 3.1.0
and try to build again.
First, make sure you have successfully built and installed vtk on your system;
Then,by using command "locate STLReader" or "locate vtkOBJReader" to ensure "vtkOBJReader" or "STLReader" libs are found in some specific directories. If vtkOBJReader or STLReader related files are found. It means that vtk has changed its structure in the new version, e.g. move vtkOBJReader into a sub library vtkIOGeometry, so you have to tell cmake to find vtkIOGeometry if you want to use that class.
Last, modify opencv3/cmake/OpenCVDetectVTK.cmake, for every find_package(VTK QUIET COMPONENTS ... add an entry vtkIOGeometry.
Success!
I'm cross-compiling the Dart runtime using the instruction here.
I've installed all the dependencies as specified. I've also cloned the git repository with the necessary tool chain.
I'm running the runtime compilation with this command:
./tools/build.py -m release -a arm --toolchain=../tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf runtime
The compilation starts with no problem then it stops with this error:
LINK(target) out/ReleaseXARM/libdart_dependency_helper.target
CXX(host) out/ReleaseXARM/obj.host/libdart_lib_withcore/runtime/vm/bootstrap.o
In file included from /usr/include/sys/socket.h:38:0,
from /usr/include/netinet/in.h:23,
from /usr/include/arpa/inet.h:22,
from runtime/platform/globals.h:56,
from runtime/platform/assert.h:16,
from runtime/vm/allocation.h:8,
from runtime/vm/bootstrap.h:9,
from runtime/vm/bootstrap.cc:5:
/usr/include/bits/socket.h:345:24: fatal error: asm/socket.h: No such file or directory
#include <asm/socket.h>
^
compilation terminated.
CXX(host) out/ReleaseXARM/obj.host/libdart_lib_withcore/gen/async_gen.o
In file included from /usr/include/sys/socket.h:38:0,
from /usr/include/netinet/in.h:23,
from /usr/include/arpa/inet.h:22,
from runtime/platform/globals.h:56,
from runtime/platform/assert.h:16,
from runtime/vm/allocation.h:8,
from runtime/vm/bootstrap.h:9,
from out/ReleaseXARM/obj/gen/async_gen.cc:5:
/usr/include/bits/socket.h:345:24: fatal error: asm/socket.h: No such file or directory
#include <asm/socket.h>
^
compilation terminated.
runtime/libdart_lib_withcore.host.mk:978: recipe for target 'out/ReleaseXARM/obj.host/libdart_lib_withcore/runtime/vm/bootstrap.o' failed
make: *** [out/ReleaseXARM/obj.host/libdart_lib_withcore/runtime/vm/bootstrap.o] Error 1
make: *** Waiting for unfinished jobs....
runtime/libdart_lib_withcore.host.mk:986: recipe for target 'out/ReleaseXARM/obj.host/libdart_lib_withcore/gen/async_gen.o' failed
make: *** [out/ReleaseXARM/obj.host/libdart_lib_withcore/gen/async_gen.o] Error 1
BUILD FAILED
Am I missing any dependency or package?
I hit the same problem. On my ubuntu 14.04 system /usr/include/asm didn't exist. It was called asm-generic instead. I sym-linked it and the build was able to continue.
cd /usr/include
sudo ln -s asm-generic/ asm
The build was able to continue after that.
This is probably because you're trying to build an application without some of the include paths correctly set, for example using a 32-bit gcc on a 64-bit platform.
To resolve:
sudo apt-get install gcc-multilib
I'm not sure why this happens, but sometimes /usr/include/asm gets deleted. My teammates who looked at their Ubuntu x86-64 workstations found that the asm symlink was:
0 lrwxrwxrwx 1 root root 20 May 22 2013 /usr/include/asm -> x86_64-linux-gnu/asm
And the command to recreate it is:
$ cd /usr/include
$ sudo ln -s x86_64-linux-gnu/asm asm
The files in /usr/include/asm-generic are sometimes, but not always, equivalent to the files in the x86-64 specific directory; so it's difficult to recommend symlinking it as a workaround.
At first I take the message sample.gcda:stamp mismatch with graph file
the order of compilation and running is observed
hexdump -e '"%x\n"' -s8 -n4 sample.gcno -> aaa1aaaa
hexdump -e '"%x\n"' -s8 -n4 sample.gcda -> bbb2bbbb
stamp mismatch with graph file
Means that graph file has been compiled again after binaries built.
If the compilation order is correct, you could try to check if there is a compilation of the sample.cpp twice somewhere in building rules.
For example we have something like that:
g++ ... sample.cpp -o sample
g++ ... -shared sample.cpp -o sample2.o
So one file is compiled twice. It will cause that gcno file will be updated by new timestamp that will not match to gcda file anymore.
If you performed your product or application testing thoroughly and manually and spent lot of effort on it. If your objective is to get code coverage report using lcov and gcov but by mistake deleted gcno files. You can regenerate gcno files by recompiling the code but it will be generated with new timestamp and gcov reports error saying "stamp mismatch with graph file" and no code coverage report will be generated. This will result in all your testing effort getting wasted.
There is a shortcut to still generate the code coverage report. This is just a workaround and should not be relied upon all the time. Its recommended to preserve *.gcno files till your testing completes.
Note down your gcc version(gcc -v) and download its source code from one of the mirror sites
Eg - ftp://gd.tuwien.ac.at/gnu/sourceware/gcc/releases/gcc-4.4.6/gcc-4.4.6.tar.bz2
After extracting downloaded file, gcc the folder structure will be as follows
gcc-4.4.6
gcc-4.4.6/gcc
If you directly go inside gcc-4.4.6/gcc and try to do ./configure and compile(make) from there then you will encounter below problem
build/genmodes -h > tmp-modes.h
/bin/sh: build/genmodes: No such file or directory
Solution is do ./configure and make from gcc-4.4.6 and no errors will be shown related to genmodes. This will compile all modules including gcc. You may have to install mpfr and gmp modules which are needed by gcc if any error shown by ./configure
goto gcc-4.4.6/gcc/gcov.c and comment below lines and then recompile with above command
/* if (tag != bbg_stamp)
{
fnotice (stderr, "%s:stamp mismatch with graph file\n", da_file_name);
goto cleanup;
}*/
Example path of new gcov binary after compilation is gcc-4.4.6/host-x86_64-unknown-linux-gnu/gcc/gcov
Place this binary in /usr/bin and regenerate code coverage report with command as shown in below example
lcov --capture --directory ./ --output-file coverage.info ; genhtml coverage.info --output-directory /var/www/html/coverage
Now you should not get "stamp mismatch with graph file" error and you will get code coverage report properly
After upgrading to Xcode 4.3.2. I'm getting a metric ton of build errors.
A whole line of them are error code 255
gcc-4.2: error trying to exec '/usr/bin/arm-apple-darwin11-gcc-4.2.1': execvp: No such file or directory
Command /usr/bin/gcc-4.2 failed with exit code 255
I noticed that there is no /usr/bin/arm-apple-darwin11-gcc-4.2.1 file on my machine. Could this be the source of the problem?
What's the output of this command?
$ printenv | grep "CC="
It might be honoring your C Compiler (CC) selection. I was getting similar errors (through cocoapods) and doing an
$ export CC=
fixed it for me.
(I have the answer to this already; I'm going to answer my own question so that I can share what I've learned and save someone else this trouble in the future)
When I attempt to build Erlang on Solaris 10 Sparcv9, the build fails partway through:
cd lib && \
ERL_TOP=/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221 PATH=/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/bootstrap/bin:${PATH} \
make opt SECONDARY_BOOTSTRAP=true
make[1]: Entering directory `/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/lib'
make[2]: Entering directory `/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/lib/hipe'
=== Entering application hipe
make[3]: Entering directory `/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/lib/hipe/misc'
erlc -W +debug_info +warn_exported_vars +warn_missing_spec +warn_untyped_record -o../ebin hipe_consttab.erl
make[3]: *** [../ebin/hipe_consttab.beam] Bus Error (core dumped)
make[3]: Leaving directory `/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/lib/hipe/misc'
Why is this and what can I do to complete my Erlang build?
The reason that the build fails is due to a broken build environment.
In this specific case the Sun GCC build is being used. This particular version of GCC was compiled to use a mixture of the the GNU assembler and the Sun linker.
The Sparc platform is highly sensitive to alignment of code and it will fault (for example, with a bus error) if unaligned code is executed.
The GNU assembler used by the stock GCC build on Sparc Solaris 10 doesn't work so hard to automatically align functions generated by the compiler, leading to unaligned code.
The solution is to build your own GCC and make sure that you use the system assembler and linker; you can achieve this by using the following options to GCC's configure script:
--with-as=/usr/ccs/bin/as \
--without-gnu-as \
--without-gnu-ld \
--with-ld=/usr/ccs/bin/ld \
The resultant GCC build will generated properly aligned code and allow you to build Erlang successfully.