There are a number of questions already on this subject, but despite that and the help on SourceForge, I cannot generate a .gcno or .gcda file.
sample question
2nd question
My make file compiles and runs my unit tests, but does not generate any output files. Is there something obviously wrong here? Commented out lines are things I have tried before.
CPP_PLATFORM = Gcc
#CPP_PLATFORM = Clang
#CPPUTEST_CPPFLAGS += -DSUPPRESS_PRINTING
#CPPUTEST_CPPFLAGS += -fprofile-arcs
#CPPUTEST_CPPFLAGS += -ftest-coverage
#GCOVFLAGS = -fprofile-arcs -ftest-coverage
#CPPUTEST_LDFLAGS += -lssl
#CPPUTEST_LDFLAGS += -lcrypto
#CPPUTEST_LDFLAGS += -fprofile-arcs
CPPUTEST_CPPFLAGS = -DSUPPRESS_PRINTING
CPPUTEST_CPPFLAGS = -fprofile-arcs:$(CPPUTEST_CPPFLAGS)
CPPUTEST_CPPFLAGS = -ftest-coverage:$(CPPUTEST_CPPFLAGS)
CPPUTEST_LDFLAGS = -lssl
CPPUTEST_LDFLAGS = -lcrypto:$(CPPUTEST_LDFLAGS)
CPPUTEST_LDFLAGS = -fprofile-arcs:$(CPPUTEST_LDFLAGS)
CPPUTEST_CPPFLAGS += -g -O0 --coverage
#CPPUTEST_CPPFLAGS += -fprofile-arcs
#CPPUTEST_CPPFLAGS += -ftest-coverage
CPPUTEST_LDFLAGS += -lprofile_rt
Either the -g -O0 --coverage or -fprofile-arcs -ftest-coverage along with the link flag do the trick. The key was the link flag.
Related
I am trying to link guile to an Rcpp file. It seems like things compile but there is an error when loading:
sourceCpp("test_2.cpp", rebuild = TRUE, showOutput = TRUE)
/usr/lib/R/bin/R CMD SHLIB --preclean -o 'sourceCpp_2.so' 'test_2.cpp'
g++-10 -I"/usr/share/R/include" -DNDEBUG -I"/home/matias/R/x86_64-pc-linux-gnu-library/4.0/Rcpp/include" -I"/home/matias/Documentos/Program/R/guile" -fpic -O3 -march=native -mtune=native -fPIC -pthread -I"/usr/include/guile/3.0" -c test_2.cpp -o test_2.o
g++-10 -shared -L/usr/lib/R/lib -lm -ldl -lgmpxx -lgmp -lmpfr -lmpc -lguile-3.0 -lgc -o sourceCpp_2.so test_2.o -L/usr/lib/R/lib -lR
Error in dyn.load("/tmp/Rtmpm2flY8/sourceCpp-x86_64-pc-linux-gnu-1.0.5/sourcecpp_29e2d33505085/sourceCpp_2.so") :
unable to load shared object '/tmp/Rtmpm2flY8/sourceCpp-x86_64-pc-linux-gnu-1.0.5/sourcecpp_29e2d33505085/sourceCpp_2.so':
/tmp/Rtmpm2flY8/sourceCpp-x86_64-pc-linux-gnu-1.0.5/sourcecpp_29e2d33505085/sourceCpp_2.so: undefined symbol: scm_init_guile
The linking works fine if I remove the Rcpp header and build directly with g++ instead.
My Makevars look like this:
CXX = g++-10
CXXFLAGS = -O3 -march=native -mtune=native -fPIC -pthread -I"/usr/include/guile/3.0"
CXXSTD = -std=c++11
LDFLAGS = -lm -ldl -lgmpxx -lgmp -lmpfr -lmpc -lguile-3.0 -lgc
The .cpp file:
#include <Rcpp.h>
#include <stdio.h>
#include <libguile.h>
using namespace Rcpp;
// [[Rcpp::export]]
int test_guile() {
SCM func, func2;
scm_init_guile();
scm_c_primitive_load("script.scm");
func = scm_variable_ref(scm_c_lookup("simple-func"));
func2 = scm_variable_ref(scm_c_lookup("quick-test"));
scm_call_0(func);
scm_call_0(func2);
return 0;
}
You are so, so close. You essentially solved this. I just took your file, made a small modification of making the script an argument and (as you didn't post script.scm) commented out the content-specific stuff. We still load it though:
#include <Rcpp.h>
#include <stdio.h>
#include <libguile.h>
using namespace Rcpp;
// [[Rcpp::export]]
int test_guile(std::string file) {
SCM func, func2;
scm_init_guile();
scm_c_primitive_load(file.c_str());
//func = scm_variable_ref(scm_c_lookup("simple-func"));
//func2 = scm_variable_ref(scm_c_lookup("quick-test"));
//scm_call_0(func);
//scm_call_0(func2);
return 0;
}
Similarly I just added a src/Makevars to the Rcpp.package.skeleton() created file. This is not good enough to ship as you need some minimal configure or alike logic to get these values from guile-config-3.0 or alike. But it passes the litmus test. C++11 is the default already under R 4.0.*, and the compiler is recent on my box anyway so we just have this (after removing a few GNU GMP and related parts we do not need):
PKG_CXXFLAGS = -I"/usr/include/guile/3.0"
PKG_LIBS = -lguile-3.0 -lgc
This now builds, installs, and runs just fine:
> file <- system.file("guile", "script.scm", package="RcppGuile")
> RcppGuile::test_guile(file)
[1] 0
>
For reference, I committed and pushed the entire example package here. If you provide a pointer to script.scm we can add that too.
Edit: A few seconds of googling leads to the script.scm you may have used so now we have a fully working example with a working embedded Guile interpreter:
> library(RcppGuile)
> test_guile(system.file("guile", "script.scm", package="RcppGuile"))
Script called, now I can change this
Adding another function, can modify without recompilation
Called this, without recompiling the C code
[1] 0
>
I have two files:
main.c will become module calc, it will use API in expression.c.
livepatch-calc.c will become module livepatch-calc.
I have following makefile and work well
obj-m += calc.o
obj-m += livepatch-calc.o
calc-objs += main.o expression.o
ccflags-y := -std=gnu99 -Wno-declaration-after-statement
Currently, I need call expression's API in livepatch-calc.c. So, I have new makefile like:
obj-m += calc.o
obj-m += livepatch-calc.o
calc-objs += main.o expression.o
livepatch-calc-objs += expression.o
ccflags-y := -std=gnu99 -Wno-declaration-after-statement
Unfortunately, when I make it. Warning message show up:
WARNING: modpost: missing MODULE_LICENSE() in ..../livepatch-calc.o
I wondering are there anything wrong in my makefile?
I'm trying to use CUDA with Qt Creator, Win7, and VS2012 compiler. I have experience with Qt on Windows, but have been unsuccessful setting up to integrate CUDA code into a Qt project. I've tried several posted solutions (such as Compiling Cuda code in Qt Creator on Windows), but have had no success. I finally decided to simplify and base my code on this blog post: https://cudaspace.wordpress.com/2012/07/05/qt-creator-cuda-linux-review/ but am still having issues.
Currently, I get the error "LNK1104: cannot open file 'obj\cuda_code.obj'"
My .pro file is:
QT += core
QT -= gui
TARGET = QtCuda
CONFIG += console
CONFIG -= app_bundle
TEMPLATE = app
SOURCES += main.cpp \
cuda_code.cu
# project build directories
DESTDIR = $$PWD
OBJECTS_DIR = $$DESTDIR/obj
# C++ flags
QMAKE_CXXFLAGS_RELEASE =-O3
# Cuda sources
CUDA_SOURCES += cuda_code.cu
# Path to cuda toolkit install
CUDA_DIR = "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.0"
# Path to header and libs files
INCLUDEPATH += $$CUDA_DIR/include
QMAKE_LIBDIR += $$CUDA_DIR/lib/x64
# libs used in your code
LIBS += -lcudart -lcuda
# GPU architecture
CUDA_ARCH = sm_50
# Here are some NVCC flags I've always used by default.
NVCCFLAGS = --compiler-options -use_fast_math
# Prepare the extra compiler configuration (taken from the nvidia forum - i'm not an expert in this part)
CUDA_INC = $$join(INCLUDEPATH,' -I','-I',' ')
cuda.commands = $$CUDA_DIR/bin/nvcc -m64 -O3 -arch=$$CUDA_ARCH -c $$NVCCFLAGS \
$$CUDA_INC $$LIBS ${QMAKE_FILE_NAME} -o ${QMAKE_FILE_OUT} \
2>&1 | sed -r \"s/\\(([0-9]+)\\)/:\\1/g\" 1>&2
cuda.dependency_type = TYPE_C
cuda.depend_command = $$CUDA_DIR/bin/nvcc -O3 -M $$CUDA_INC $$NVCCFLAGS ${QMAKE_FILE_NAME}
cuda.input = $$CUDA_SOURCES
cuda.output = $$OBJECTS_DIR/${QMAKE_FILE_BASE}_cuda.obj
# Tell Qt that we want add more stuff to the Makefile
QMAKE_EXTRA_COMPILERS += cuda
My main.cpp
#include <QtCore/QCoreApplication>
#include <iostream>
using namespace std;
#include <cuda_runtime.h>
extern "C"
cudaError_t cuda_main();
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
cudaError_t cuerr = cuda_main();
if (cuerr != cudaSuccess) cout << "CUDA Error: " << cudaGetErrorString( cuerr ) << endl;
return a.exec();
}
My cuda file (cuda_code.cu):
#include <thrust/host_vector.h>
#include <thrust/device_vector.h>
#include <thrust/sort.h>
extern "C"
cudaError_t cuda_main()
{
// generate 16M random numbers on the host
thrust::host_vector<int> h_vec(1 << 24);
thrust::generate(h_vec.begin(), h_vec.end(), rand);
// transfer data to the device
thrust::device_vector<int> d_vec = h_vec;
// sort data on the device (805 Mkeys/sec on GeForce GTX 480)
thrust::sort(d_vec.begin(), d_vec.end());
// transfer data back to host
thrust::copy(d_vec.begin(), d_vec.end(), h_vec.begin());
return cudaGetLastError();
}
The OP was able to get a successful compile link by making the following changes:
1) In the .pro file, added
MSVCRT_LINK_FLAG_DEBUG = "/MDd"
MSVCRT_LINK_FLAG_RELEASE = "/MD"
along with (to the cuda.command statement)
-Xcompiler $$MSVCRT_LINK_FLAG_DEBUG -or- -Xcompiler $$MSVCRT_LINK_FLAG_RELEASE
as described in:
Compile cuda file error: "runtime library" mismatch value 'MDd_DynamicDebug' doesn't match value 'MTd_StaticDebug' in vectorAddition_cuda.o
2) Also had a very strange detail in the makefile that I had to fix manually. I hope that there is a real fix for this, but I haven't been able to figure it out.
At the top of the makefile, there are several definitions, including one for LIBS. After close inspection of this definition, I found that there was an extra set of quotation marks in the specification of library locations. Like this:
LIBS = /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\lib\x64" ""C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\lib\x64"\cuda.lib" ""C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\lib\x64"\cudart.lib" /LIBPATH:C:\Qt\5.2.1\msvc2012_64_opengl\lib C:\Qt\5.2.1\msvc2012_64_opengl\lib\Qt5Cored.lib
If you look closely, you can see the extra set of quotation marks in the locations for cuda.lib and cudart.lib. I couldn't figure out what might be causing this (probably something in my .pro file), but if I manually removed the extra quotations, the compile/link worked. Here's the corrected line in the makefile:
LIBS = /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\lib\x64" "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\lib\x64\cuda.lib" "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.0\lib\x64\cudart.lib" /LIBPATH:C:\Qt\5.2.1\msvc2012_64_opengl\lib C:\Qt\5.2.1\msvc2012_64_opengl\lib\Qt5Cored.lib
I would sure like to be able to fix this in my .pro file so that these extra quotations didn't appear. Suggestions would be appreciated.
For reference, here's my latest .pro file.
QT += core
QT -= gui
TARGET = QtCuda
CONFIG += console
CONFIG -= app_bundle
TEMPLATE = app
SOURCES += main.cpp \
cuda_code.cu
# project build directories
DESTDIR = $$PWD
OBJECTS_DIR = $$DESTDIR/obj
# C++ flags
QMAKE_CXXFLAGS_RELEASE =-O3
# Cuda sources
CUDA_SOURCES += cuda_code.cu
# Path to cuda toolkit install
CUDA_DIR = "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.0"
# Path to header and libs files
INCLUDEPATH += $$CUDA_DIR/include
QMAKE_LIBDIR += $$CUDA_DIR/lib/x64
SYSTEM_TYPE = 64 # '32' or '64', depending on your system
# libs used in your code
LIBS += -lcuda -lcudart
# GPU architecture
CUDA_ARCH = sm_50
# Here are some NVCC flags I've always used by default.
NVCCFLAGS = --use_fast_math
# Prepare the extra compiler configuration (taken from the nvidia forum - i'm not an expert in this part)
CUDA_INC = $$join(INCLUDEPATH,'" -I"','-I"','"')
# MSVCRT link option (static or dynamic, it must be the same with your Qt SDK link option)
MSVCRT_LINK_FLAG_DEBUG = "/MDd"
MSVCRT_LINK_FLAG_RELEASE = "/MD"
# Tell Qt that we want add more stuff to the Makefile
QMAKE_EXTRA_COMPILERS += cuda
# Configuration of the Cuda compiler
CONFIG(debug, debug|release) {
# Debug mode
cuda_d.input = CUDA_SOURCES
cuda_d.output = $$OBJECTS_DIR/${QMAKE_FILE_BASE}.obj
cuda_d.commands = $$CUDA_DIR/bin/nvcc.exe -D_DEBUG $$NVCC_OPTIONS $$CUDA_INC $$LIBS --machine $$SYSTEM_TYPE \
-arch=$$CUDA_ARCH -c -o ${QMAKE_FILE_OUT} ${QMAKE_FILE_NAME} -Xcompiler $$MSVCRT_LINK_FLAG_DEBUG
cuda_d.dependency_type = TYPE_C
QMAKE_EXTRA_COMPILERS += cuda_d
}
else {
# Release mode
cuda.input = CUDA_SOURCES
cuda.output = $$CUDA_OBJECTS_DIR/${QMAKE_FILE_BASE}.obj
cuda.commands = $$CUDA_DIR/bin/nvcc.exe $$NVCC_OPTIONS $$CUDA_INC $$LIBS --machine $$SYSTEM_TYPE \
-arch=$$CUDA_ARCH -c -o ${QMAKE_FILE_OUT} ${QMAKE_FILE_NAME} -Xcompiler $$MSVCRT_LINK_FLAG_RELEASE
cuda.dependency_type = TYPE_C
QMAKE_EXTRA_COMPILERS += cuda
}
[Note: this answer has been created from an edit to the question which included the solution. It has been added as a community wiki entry to get the question off the unanswered list for the CUDA tag]
I tryies to init OpenGL on windows without GLFW ... her some relevant code:
#include <windows.h>
//...
if(!(g_hDC = GetDC(hWnd)))
return false;
if(!(iPixelFormat = ChoosePixelFormat(g_hDC, &pfdPixelFormat)))
return false;
if(!SetPixelFormat(g_hDC, iPixelFormat, &pfdPixelFormat))
return false;
if(!(g_hRC = wglCreateContext(g_hDC)))
return false;
if(!wglMakeCurrent(g_hDC, g_hRC))
return false;
//...
when I compile with mingw32-g++ -Wall -O2 -Wl,--subsystem,windows -lopengl32 -mwindows Init.c I get following errors:
Temp\cclcIFFB.o:init.c:(.text+0x281): undefined reference to `_wglCreateContext#4'
Temp\cclcIFFB.o:init.c:(.text+0x2a0): undefined reference to `_wglMakeCurrent#8'
collect2.exe: error: ld returned 1 exit status
Why this linker error acours?
Try putting your Init.c before the -lopengl32:
mingw32-g++ -Wall -O2 Init.c -Wl,--subsystem,windows -lopengl32 -mwindows
gcc can be picky about argument positioning.
You must add the OpenGL linker definition library opengl32.lib to the list of to be linked libraries.
I am using libtool 2.2.6b on ubuntu lucid, and libtool 2.4.2 on ubuntu precise. On lucid my project will link properly. On precise it fails to link. Here's example code that demonstrates my problem;
configure.ac
AC_INIT([ltp], [0.0.1], [someone])
AM_INIT_AUTOMAKE
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_MACRO_DIR([.m4])
AC_CONFIG_FILES([Makefile foo/Makefile bar/Makefile wah/Makefile])
AC_PROG_CXX
AC_PROG_LIBTOOL
AM_SANITY_CHECK
AC_LANG_CPLUSPLUS
AC_OUTPUT
Makefile.am
SUBDIRS = foo bar wah
ACLOCAL_AMFLAGS = -I .m4
foo/Foo.h
#ifndef FOO_FOO_H_
#define FOO_FOO_H_
namespace Foo
{
class Foo
{
public:
Foo(long l);
private:
long l;
};
}
#endif
foo/Foo.cpp
#include "foo/Foo.h"
namespace Foo
{
Foo::Foo(long l) : l(l) {}
}
foo/Makefile.am
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = Foo.cpp
libfoo_la_CPPFLAGS =
libfoo_la_LDFLAGS = -release 0.0.1
libfoo_la_LIBADD =
bar/Bar.h
#ifndef BAR_BAR_H_
#define BAR_BAR_H_
#include "foo/Foo.h"
namespace Bar
{
class Bar
{
public:
Bar(const Foo::Foo & f);
private:
Foo::Foo f;
};
}
#endif
bar/Bar.cpp
#include "bar/Bar.h"
namespace Bar
{
Bar::Bar(const Foo::Foo & f) : f(f) { }
}
bar/Makefile.am
lib_LTLIBRARIES = libbar.la
libbar_la_SOURCES = Bar.cpp
libbar_la_CPPFLAGS =
libbar_la_LDFLAGS = -release 0.0.1
libbar_la_LIBADD = -L../foo -lfoo
wah/main.cpp
#include "bar/Bar.h"
int main(int argc, char * argv[])
{
Bar::Bar( 5 );
return 0;
}
wah/Makefile.am
bin_PROGRAMS = wah
wah_SOURCES = main.cpp
wah_CPPFLAGS =
wah_LDADD = -L../bar -lbar
On Lucid, wah links, on Precise, it fails with:
wah/main.cpp:5 undefined reference to `Foo::Foo::Foo(long)'
I can fix this by adding -L../foo -lfoo to wah_LDADD, but really, isn't libtool supposed to do that for me automagically? The libtool manual section on `Linking executables' seems to indicate that is exactly what it should do.
On any Debian machine I use for development, I have to compile and install Libtool by hand, because the Debian-supplied version is patched and ignores dependencies in a way that break my builds.
If Ubuntu's version is similar, you might want to install Libtool from source too.
I suppose you could say it's more of a difference in philosophy. The point of Debian's change is to encourage users to be explicit about what they depend on, which reduces the amount of unnecessary churn when dependencies deep down the tree get upgraded.
When link_all_deplibs=yes (unmodified libtool), if your program wah depends on bar and bar depends on foo, then it is implied that wah depends foo as well.
When link_all_deplibs=no (Debian's modified libtool), if your program wah depends on bar and bar depends on foo, then it is not implied that wah depends foo as well.
So, taking Debian's perspective, this is false in your program: wah does depend on foo by virtue of this line:
Bar::Bar( 5 );
Here, you are calling the constructor of Foo::Foo implicitly. As far as the C++ compiler is concerned, your program is really more like:
Bar::Bar( Foo::Foo( 5 ) );
Therefore, wah depends on foo not just indirectly, but directly. Hence, from Debian's perspective, you are should explicitly link to foo via -lfoo.
In particular, this is not the same situation as libtool's example for Linking Executables. In that example, main.o does not explicitly depend on libm, thus -lm should, in principle, be unnecessary when linking the main.o (main.c does not call cos directly). Perhaps the reason why libtool links recursively is as a work around for older systems where linkers are unable to handle indirect dependencies?
Works for me on Ubuntu 12.04 (Precise Pangolin) 32-bit, libtool 2.4.2.
I did have to change your Makefiles a bit to make dist (more) correctly:
foo/Makefile.am:
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = Foo.cpp Foo.h
libfoo_la_CPPFLAGS =
libfoo_la_LDFLAGS = -release 0.0.1
libfoo_la_LIBADD =
bar/Makefile.am:
lib_LTLIBRARIES = libbar.la
libbar_la_SOURCES = Bar.cpp Bar.h
libbar_la_CPPFLAGS =
libbar_la_LDFLAGS = -release 0.0.1
libbar_la_LIBADD = -L../foo -lfoo
wah/Makefile.am
bin_PROGRAMS = wah
wah_SOURCES = main.cpp ../bar/Bar.h
wah_CPPFLAGS =
wah_LDADD = -L../bar -lbar
Here's how it links main.cpp:
make[2]: Entering directory `/xxx/ltp-0.0.1/wah'
g++ -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT wah-main.o -MD -MP -MF .deps/wah-main.Tpo -c -o wah-main.o `test -f 'main.cpp' || echo './'`main.cpp
mv -f .deps/wah-main.Tpo .deps/wah-main.Po
/bin/bash ../libtool --tag=CXX --mode=link g++ -g -O2 -o wah wah-main.o -L../bar -lbar
libtool: link: g++ -g -O2 -o .libs/wah wah-main.o -L../bar /xxx/ltp-0.0.1/bar/.libs/libbar.so -L../foo /xxx/ltp-0.0.1/foo/.libs/libfoo.so
isn't libtool supposed to do that for me automagically?
Yes, it does, at least when the distribution tarball is created on a non-Ubuntu distribution. After I autoreconf on an Ubuntu box, I get the same error you do.
Apparently (according to adl) the Ubuntu distro has a patched version of libtool which sets the libtool script variable:
link_all_deplibs=no
I patched the configure generated libtool script to replace all these instances with:
link_all_deplibs=unknown
and everything linked as expected. I suppose you could do the same in a script that invokes autoreconf. Or install a non-patched version of libtool on the Ubuntu host. Or patch the patched libtool on the Ubuntu host. So there's a few options on how to fix it.