I have a CMake/CTest configuration set up and all works fine. The problem is that we have one test runner that has several versions of GCC in use and for this project I'll have to use non-standard location of the compiler. So for example instead of using standard /usr/bin/gcc I'll be using /mnt/data/gcc/8.4.0/bin/gcc.
For compilation point of view everything goes well when using -DCMAKE_C_COMPILER=/mnt/data/gcc/8.4.0/bin/gcc when creating the CMake project, but when I run ctest -T coverage CTest wants to use /usr/bin/gcov which is incompatible with the compiler. How can I set the CTest to use /mnt/data/gcc/8.4.0/bin/gcov instead?
I've tried to set the value of CTEST_COVERAGE_COMMAND in CTestConfig.cmake, but it does not have any effect.
Related
Using GtkAda, I'm trying to use the resource API to include the Glade file directly inside my code.
For this, we can generate C code from a set of resources using glib-compile-resources which can then be linked to the Ada code.
The problem is that this C code requires Gtk includes which we usually get from the pkg-config command under Linux such as
gcc -c -x c `pkg-config --cflags gio-2.0` myglade.gresource.c
I'd like to know how to provide the same kind of information in a GPRBuild project file.
FYI, I already tried to use the pkg-config command inside the compiler package for C language without any success. Of course, I managed to build by hand but that's a bit long :)
This might work for you:
project Config_Demo is
Pkg_Config := external_as_list ("PKG_CONFIG", " ");
package Compiler is
-- only this file needs the extra switches
for Switches ("myglade.gresource.c") use Pkg_Config;
end Compiler;
end Config_Demo;
and then
gprbuild -P config_demo -XPKG_CONFIG="`pkg-config -cflags gio-2.0`"
Your best bet will be to do what GtkAda does: Look at its shared.gpr.in file, it uses the token #GTK_LIBS_GPR# which will be replaced by the configure script, giving a usable shared.gpr.
Thing is, you need to issue the pkg-config call and build your gpr file from the result somehow. GPRBuild is not equipped to do this for you and process the result. If you're comfortable with GNU autotools, you can look further at how GtkAda achieves it:
GTK_LIBS_GPR is set in aclocal.m4 using a macro that converts the C-style flags to a GPR array. The value comes from GTK_LIBS which is queried here via pkg-config.
If you're not comfortable with GNU autotools, you can write your configure script using basic shell commandos, a scripting language like Python or with whatever other tool you're comfortable with.
I have been using the deploytool in Matlab for the past few months in my 2010b 64bit version of Matlab. I just recently found out that I need to create a 32 bit version of my c shared library.
To do this I follow the same methods I had been using previously (pretty much calling the command mcc -W lib:MYLIB -T link:lib -d 'MYOUTPUTFOLDER' -v 'MFILE1' 'MFILE2') in my 2009b 32 version of Matlab. I keep getting the error LNK1811: cannot open input file LIBRARY.obj. I have tried to find this LIBRARY object file but I cannot seem to find it anywhere.
So far I have checked to ensure all of the correct libraries are available (found at $MATLABROOT$\extern\include\win32), I have made sure all of my paths are correct in the compopts.bat file, and I have used the option -T compile:lib which works fine and creates a dll. This would be great but I need a lib file to use later in mbuild.
My current path forward is to take the compopts from my 64 bit version of Matlab (on a different machine) and compare it with my compopts for the 32 bit. I will post if it makes a difference.
To summarize our comments in the question and make it an answer. Here is how I manage to create both x32 and x64 libraries/standalones with mcc.
NB: Maybe there are more elegant solutions to configure deploytool, anyway with brute force I'm sure it works and I can automate global deployment process for my applications ...
Machine setup
Install Matlab x32 and x64 on your machine
Run Matlab x32 and setup compiler options typing msbuild -setup
This will generate a compopts.bat file in ~user\AppData\Roaming\MathWorks\MATLAB\R2013b (path may differ upon your version)
Rename this file to compopts.x32.bat (see later)
Run Matlab x64 and setup compiler options typing msbuild -setup
This will generate a compopts.bat file in ~user\AppData\Roaming\MathWorks\MATLAB\R2013b (!!Overwrites x32!!)
Rename this file to compopts.x64.bat (To workaround file overwrite)
EDIT Just tested ... In R2014b, Matlab does no longer overwrites same compots.bat file ... it now generates two separate MBUILD_C++_win64.xml and MBUILD_C++_win32.xml files (which is a good thing!).
Compilation in x32
Force your compilation script to point to ~matlabx32\bin\win32\mcc.exe and force mcc.exe to use previously saved compopts.x32.bat file using the -f option. Your command line should be something like:
~matlabx32\bin\win32\mcc.exe -f "compopts.x32.bat" ... other mcc options ...
Compilation in x64
Force your compilation script to point to ~matlabx64\bin\win64\mcc.exe and force mcc.exe to use previously saved compopts.x64.bat file using the -f option. Your command line should be something like:
~matlabx64\bin\win64\mcc.exe -f "compopts.x64.bat" ... other mcc options ...
I am constructing an R package where I have few third party C functions which use GSL and OpenMP, and I then call these from R using wrappers made with Rcpp (which just modify some arguments and call the appropriate C function). Everything works fine in my Windows machine, but I am not sure how to define the Makevars.win and Makevars file in a portable way. My Makevars.win looks like this:
## This assumes that the LIB_GSL variable points to working GSL libraries
PKG_CPPFLAGS=-I$(LIB_GSL)/include -I../inst/include
PKG_LIBS=-L$(LIB_GSL)/lib/x64 -lgsl -lgslcblas $(SHLIB_OPENMP_CFLAGS)
PKG_CFLAGS=$(SHLIB_OPENMP_CFLAGS)
It is basically copied from various sources. Like said, this compiles in my computer (using toolchain of from Rtools), and if I remove PKG_CFLAGS=$(SHLIB_OPENMP_CFLAGS) I can also compile without OpenMP (for some reason I don't understand I get error if I remove OpenMP flag in PKG_LIBS).
My Makevars file looks identical, but I don't have access to Unix platforms so I am not sure how to deal with that side. My guess is that I need to replace LIB_GSL with something?
EDIT:
Okay, I think I finally understand how configure etc. works and was able to get everything working.
My Makevars.win:
## This assumes that the LIB_GSL variable points to working GSL libraries
PKG_CPPFLAGS=-I$(LIB_GSL)/include -I../inst/include
PKG_LIBS="-L$(LIB_GSL)/lib/$(R_ARCH)" -lgsl -lgslcblas $(SHLIB_OPENMP_CFLAGS)
PKG_CFLAGS=$(SHLIB_OPENMP_CFLAGS)
My Makevars.in:
GSL_CFLAGS = #GSL_CFLAGS#
GSL_LIBS = #GSL_LIBS#
PKG_LIBS=$(GSL_LIBS) $(SHLIB_OPENMP_CFLAGS)
PKG_CFLAGS=$(GSL_CFLAGS) $(SHLIB_OPENMP_CFLAGS)
And my configure.ac:
AC_INIT([testpackage], 0.0.1)
## Use gsl-config to find arguments for compiler and linker flags
##
## Check for non-standard programs: gsl-config(1)
AC_PATH_PROG([GSL_CONFIG], [gsl-config])
## If gsl-config was found, let's use it
if test "${GSL_CONFIG}" != ""; then
# Use gsl-config for header and linker arguments
GSL_CFLAGS=`${GSL_CONFIG} --cflags`
GSL_LIBS=`${GSL_CONFIG} --libs`
else
AC_MSG_ERROR([gsl-config not found, is GSL installed?])
fi
# Now substitute these variables in src/Makevars.in to create src/Makevars
AC_SUBST(GSL_CFLAGS)
AC_SUBST(GSL_LIBS)
AC_OUTPUT(src/Makevars)
I then run autoconf in testpackage directory in order to get configure file, which in turn converts Makevars.in to Makevars when running R CMD INSTALL.
There are a few CRAN packages using the GSL, and/or our RcppGSL bindings. Here is what I do in one of these (my RcppZiggurat package):
PKG_CPPFLAGS = -I. -I../inst/include
## Use the R_HOME indirection to support installations of multiple R version
PKG_LIBS = `$(R_HOME)/bin/Rscript -e "RcppGSL:::LdFlags()"`
That is the entire /src/Makevars. You can trivially add the same OpenMP variable from R. This does of course create a dependency on RcppGSL (as I already use it in RcppZiggurat). Else you can look into the R/init.R of RcppGSL and see how it tries to talk to gsl-config and store those values. You can do the same in src/Makevars -- it is just basic Make usage and nothing Rcpp specific.
I'm currently trying to setup a CMake project with two executables, one of which is a simple utility used to generate code for the other. Relevant bits of CMakeLists.txt:
add_executable(lua2c lua2c.c)
add_custom_command(OUTPUT lcode.c COMMAND lua2c lcode.lua lcode.c MAIN_DEPENDENCY lua2c)
...
add_executable(darpem ... lcode.c)
With this setup, target lua2c winds up with no dependencies, which causes cc to complain about no input files. If I remove the add_custom_command line, then lua2c is built properly, but obviously doesn't generate the file lcode.c. Is this possible in CMake? Would I need to add a subdirectory dependency of sorts?
Using CMake version 2.8.1 on Ubuntu 13.04, x86-64.
NOTE: For my particular case, because lua2c is simple enough, I can use a different language. I am, however, still curious as to how this might be possible (for more complex setups).
From the documentation :
Note that MAIN_DEPENDENCY is completely optional and is used as a suggestion to visual studio about where to hang the custom command.
Maybe this should solve your problem :
add_executable(lua2c lua2c.c)
add_custom_command(OUTPUT lcode.c COMMAND lua2c lcode.lua lcode.c DEPENDS lua2c)
# ^^^^^^^
...
add_executable(darpem ... lcode.c)
Or if it doesn't work, this one should work :
add_executable(lua2c lua2c.c)
add_custom_command(TARGET lua2c
POST_BUILD
COMMAND lua2c lcode.lua lcode.c )
...
add_executable(darpem ... lcode.c)
add_dependencies( darpem lua2c )
It simply add a post build event after the build of lua2c. And it add lua2c as a dependency of darpem.
While debugging a C program in gdb I have a breakpoint in a for loop. I cannot print the value of "i" ( I get : No symbol "i" in current context.). I can print the value of all the other variables. Is it normal?
Here is the loop:
for (i=0; i < datasize; i++){
if ( feature_mask[i] > 0 ){
k = feature_mask[i] - 1;
if (neighbors[k][nmax-1] != 0){
neighbors[k][nmax-1] = bvalue;
feature_mask[i] = -feature_mask[i];
}
}
}
It has probably been optimised out of your compiled code as you only use feature_mask[i] within the loop.
Did you specify an optimization level when you called your compiler? If you were using gcc, then just omit any -O options and try again.
I encountered this issue recently. I compiled GCC 5.1 and then used it to compile a C++11 codebase. And, although I could step through the program's code in gdb, I couldn't print the value of any variable, I kept getting “No symbol "xyz" in current context” errors, for every variable.
I was using gdb 7.4, but the latest version available at the time was 7.9. I downloaded the latest version of gdb and compiled it (using GCC 5.1) and when using gdb 7.9 I was able to successfully inspect variable values again.
I guess the debug information of GCC 5.1 is incompatible with gdb 7.4.
Make sure the program is compiled without optimization, and with debugging information enabled. It's quite likely that the loop counter ends up in a register.
Check your optimization options. It's possible the GCC could replace the variable with a pointer into feature_mask.
You can try declaring i as volatile. That will prevent some compiler optimizations (and hopefully make i visible inside the debugger).
In case anyone else is using Google's Bazel build system for your project, I'd like to add that if you cannot print any variables from gdb, it may be because you need to properly add the -ggdb and -O0 (update: use -Og instead of -O0 use -O0 over -Og) C build flags using the --copt= option, INSTEAD OF using the --per_file_copt= option. In my case, although they both built and ran just fine, only the --copt= technique allowed me to fully use gdb and print variables, whereas the --per_file_copt= one also allowed me to use gdb but would NOT allow me to print variables.
Note: in the below examples, just replace test with build if you do NOT need to run the unit tests as well.
UDPATE: it turns out, you should prefer -Og over -O0 when doing debugging, so I'm updating these examples accordingly. See here: What's the difference between a compiler's `-O0` option and `-Og` option?.
So, do this:
time bazel test --copt=-ggdb --copt=-O0 \
//my/build/folder1/... //my/build/folder2/...
INSTEAD OF this:
time bazel test --per_file_copt=//my/build/folder1/...,//my/build/folder2/...#-ggdb,-O0 \
//my/build/folder1/... //my/build/folder2/...
...in order to be able to print variables from within gdb.
Again, both of the above techniques build and run just fine, and both allow me to run and use gdb, but only the first one actually allows me to use gdb to its full extent.
Lastly, if the first command above still doesn't work, try adding the --strip=never Bazel flag described here to prevent Bazel from ever stripping debugging information. Now the command will look like this:
time bazel test --copt=-ggdb --copt=-O0 --strip=never \
//my/build/folder1/... //my/build/folder2/...
Reference documentation:
--copt=:
https://docs.bazel.build/versions/master/command-line-reference.html#flag--copt
[better, with examples] https://docs.bazel.build/versions/master/user-manual.html#flag--copt
--per_file_copt:
https://docs.bazel.build/versions/master/command-line-reference.html#flag--per_file_copt
[better, with examples] https://docs.bazel.build/versions/master/user-manual.html#flag--per_file_copt
--strip=never:
https://docs.bazel.build/versions/master/user-manual.html#flag--strip
[my own Q&A] Prefer -Og over -O0 -O0 over -Og for debugging: What's the difference between a compiler's `-O0` option and `-Og` option?