I am trying to generate bullseye coverage report after doing blackbox testing. We have an appliance on which we do black box testing, however there is no way to compile libraries on that, so I am following below steps to generate report.
However I am getting 0% report. There is no change in coverage file, it's not getting updated.
compile all libs with bullseye
copy and replace original libs on appliance with this bullseye libs
copy cov file, and make sure ithas proper rights (i.e. chmod 777cov_file.cov)
export path in /etc/environment, also created sh file in /etc/profile.d and set path in it.
run black box tests.
copy cov file to dev machine and generate report.
I solved the above problem by setting the environment variable from one of the demon file.
The possible reason it was not working is, I was setting environment variable in profile which requires shell, however my automation was not using shell.
Related
I'm posting here with the hopes that someone will be kind enough to help me. Just to clarify, I'm sort of a newb, so I'd be really grateful if you give more details to your explanations.
I'm on Windows 10 64 bit, QT 5.9.1, PostgreSQL is 9.6.3 version.
I'm working on a project, where I need to get a postgresql database running and connect it to the code I'm doing right now. Unfortunately, when I try to install the driver, I run into all kinds of problems. I've been reading on threads on sites, but they are outdated and some folders do not match, which my first problem arises. For some reason I cannot get qmake to work, even though I edit the path in the variables.
I tried running the commands from here.
cd %QTDIR%\qtbase\src\plugins\sqldrivers\ps
ql
qmake "INCLUDEPATH+=C:/psql/include" "LIBS+=C:/psql/lib/ms/libpq.lib" psql.pro
nmake
Basically my folders don't aren't 100% as the guide, also I don't have a libpq.lib file
On my final attempt I tried the following:
qmake "INCLUDEPATH+=C:/PostgreSQL/pg96/include" "LIBS+=C:/PostgreSQL/pg96/lib/libpq.lib"
Project ERROR: Cannot run compiler 'cl'. Maybe you forgot to setup the environment?
You'll need to have PostgreSQL installed so you have libpq.lib and libpq.dll. You cannot compile the Qt PostgreSQL driver without these. You'll also need to find the include directory for your PostgreSQL install, the one that contains libpq-fe.h.
Then determine the paths to those. Set the PATH to include the directory with libpq.dll. Set LIBS to include the directory with libpq.lib. And set the INCLUDEPATH to include the directory with libpq-fe.h.
You'll probably need to do this within a "Visual Studio Command Prompt" or run vcvarsall.bat fist, too, so qmake can find Visual Studio.
I'm trying to debug an open source package, called libprotoident in Eclipse, Kepler version, within Debian. As it has the Makefile, I choose to make an empty Makefile project, and then add all the sources into the workspace. So after that the source compiled and run successfully as in the command line using the Makefile.
As it has 4 apps you can use, I choose to run lpi_protoident package in the run configuration window, as the following image shown.
So the Program ran successfully. Now I'm trying to debug it but it generates the following error.
How can I solve this error and debug the Project?
The file you are trying to debug is most likely a shell script created by automake that acts as a wrapper around the real executable, which has been built in a hidden directory.
Instead of telling Eclipse that tools/protoident/lpi_protoident is your application, try using tools/protoident/.libs/lpi_protoident instead.
General Answer about the error you are getting
What not in executable format: File format not reconized error means is that lpi_protoident is not an executable on the platform you are working on.
Are you sure that is an executable you can run (E.g. from the command line)?
There is also the small chance that the GDB you are using is somehow incompatible with the executable, but that is less likely.
Building libprotoident from source
(Assuming you are trying to build https://github.com/wanduow/libprotoident)
You are trying to build an automake project. The normal way to do that is by configuring to create Makefile, you shouldn't be making your own makefile. Please refer to the README in the project, but the key parts you need to do are:
Installation
After having installed the required libraries, running the following series of commands should install libprotoident
./bootstrap.sh (only if you've cloned the source from GitHub)
./configure
make
make install
By default, libprotoident installs to /usr/local - this can be changed
by appending the --prefix= option to ./configure.
The libprotoident tools are built by default - this can be changed by
using the
--with-tools=no option with ./configure.
I recently started using qemu and it's a great tool when you don't have the required hardware to run your firmware (currently using it for cortex-m3).
Now what I want to do is to do some test coverage with it. I tried using GNUC ARM Eclipse, and I've been successfull compiling and executing the code in qemu, but whenever I add the -fprofile-arcs -ftest-coverage flags (for the project and then for the desired file to run coverage) I am able to create the .gcno file, which means that after executing my code it will generate a .gcda file and then I should be able to see the coverage.
Thtat's where everything goes wrong. I was able to generate a .gcda file but whenever I try to open any of them, eclipse tells me that it wasn't able to open the file because it was null. I've tried replicating the procedure in another computer, but I haven't been successful creating the gcda file (probably different binaries).
At this point I don't really know how to proceed. Should I abandon ARM Eclipse and stick to makefiles (is it possibll to run gcov this way?) or am I missing something really small that is fixable?
PS: I using windows 7 64 bits, the latest versions available on the GNU ARM Eclipse website. Also the idea of doing it via makefiles just occurred to me (it was a stresfull day, it's really late) so I haven't tried it yet, I've only tried executing the code, but without coverage.
As far as I know, qemu is not able to generate DWARF information. But there is a project with the proposal of code coverage with qemu: Couverture Project
When you use qemu as a user space emulator (see also the qemu documentation) you actually can measure the code coverage as usual. In this mode qemu has the full access to the host file system.
For a CMake project you can simply use the CROSSCOMPILING_EMULATOR property of your test executable, e.g.:
if(CMAKE_CROSSCOMPILING)
set_target_properties(mytest
PROPERTIES
CROSSCOMPILING_EMULATOR "qemu-${CMAKE_SYSTEM_PROCESSOR};-L;$ENV{SDKTARGETSYSROOT}"
)
endif()
With this setting ctest will use qemu for running the test and will write the .gcda files to the usual location in your build directory.
MATLAB 2014a (8.3) Runtime Compiler (MCR) Errors when trying to launch deployed (using
deploy tool) application in Ubuntu 13.04.
Right after installation of MCR if one runs the deployed application following error appears:
error while loading shared libraries: libmwlaunchermain.so: cannot open shared object file: No such file or directory.
Since I have already found a solution to this problem wasting a day, I just want to share it:
This seems to be a problem of MATLAB MCR installation script designed for Linux by MathWorks. Furthermore, it is a result of a known Ubuntu bug. To fix it, add your MCR to the $PATH as shown below:
First make sure to add the missing files to the right folder, in terminal:
sudo cp /usr/local/MATLAB/MATLAB_Compiler_Runtime/v83/runtime/glnxa64/* /usr/local/MATLAB/MATLAB_Compiler_Runtime/v83/bin/glnxa64
Add the proper library folder to your .profile, such that this change will stay after logout
ubuntu: gedit .profile
In the end of the file add following lines:
#MATLAB MCR
export LD_LIBRARY_PATH=/usr/local/MATLAB/MATLAB_Compiler_Runtime/v83/bin/glnxa64
export XAPPLRESDIR=/usr/local/MATLAB/MATLAB_Compiler_Runtime/v83/X11/app-defaults
export PATH=$PATH:$LD_LIBRARY_PATH
export PATH=$PATH:$XAPPLRESDIR
Invoke following code in the terminal to make sure that Ubuntu bug doesn't re-write your variable:
echo STARTUP=\"/usr/bin/env LD_LIBRARY_PATH=\${LD_LIBRARY_PATH} \${STARTUP}\" | sudo tee /etc/X11/Xsession.d/90preserve_ld_library_path
Reboot
If this solution doesn't work, try to reinstall MATLAB MCR 8.3 from the MathWorks website and repeat the steps.
In my case (Matlab R2016b = v91), the binary generated by Matlab was accompanied by a shell script which sets up the LD_LIBRARY_PATH for me. If I just run
./run_scriptname.sh
it complains about the missing <deployedMCRroot>. So running the script with
./run_scriptname.sh /home/user/MatlabMCR/v91
it worked out of the box.
For me, it was not obvious that the path shown above is the <deployedMCRroot> because I chose /home/user/MatlabMCR as installation directory. And with the wrong path specified, it led to the same error message.
I'm having trouble getting a compiled .exe file to run with MCR instead of Matlab (I can tell because the program is using multiple threads, which it would not do if it were running with MCR). The MATLAB documentation (http://www.mathworks.com/help/toolbox/compiler/f12-999353.html) says:
"To run deployed components against the MCR install, mcr_root\ver\runtime\win32|win64 must appear on your system path before matlabroot\runtime\win32|win64.
If mcr_root\ver\runtime\arch appears first on the compiled application path, the application uses the files in the MCR install area.
If matlabroot\runtime\arch appears first on the compiled application path, the application uses the files in the MATLAB Compiler installation area."
Can anyone connect the dots a bit more for me? I don't know what this means. Thanks!
I had the same problem: my compiled code was multithreaded, which I did not want.
The problem got solved by compiling with the option:
-R -singleCompThread
You need to set properly the PATH global environment variable in Windows. How you do it exactly depends on Windows version.
Here is the first link from Google by query "set path on Windows": http://www.computerhope.com/issues/ch000549.htm
This variable is a list of directories. Make sure you have a directory with MCR executable earlier in this list than a directory with MATLAB executable.