Compiling R extension with third-party DLL - r

I am writing an R extension that includes C code that relies on a third-party DLL. Compilation is being done on Windows using Rtools with R 2.11.0. My plan is that the DLL will be distributed with the source package and stored in the extension's src directory. My question then is how I can cause the compiler to look in the the src directory when it tries to link to the third-party DLL.
Currently, I am building the package with the command:
R CMD build --binary MyPackage
I also have a file src/Makevars with the following line:
PKG_LIBS = -ldlxapi32
This ensures that the third-party DLL, dlxapi32.dll, is included in compilation. However, the compiler cannot find the DLL, since my package's src directory is not part of the standard library search path.
I have tried to remedy this by changing src/Makevars to read:
PKG_LIBS = -L$(CURDIR) -ldlxapi32
But this fails with output like the following:
gcc -shared -s -static-libgcc -o MyPackage.dll tmp.def dlx.o -L/cygdrive/c/DOCUME~1/abiel/LOCALS~1/Temp/Rbuild709236257/MyPackage/src -ldlxapi32 -Lc:/PROGRA~1/R/R-211~1.0/bin -lR
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: cannot find -ldlxapi32
Here, we can see that $(CURDIR) evaluated to /cygdrive/c.DOCUME~1/... I was hoping that instead it would evaluate to C:/programming/r/MyPackage/src, which is the actual location of the src directory. Is there a way to fix this?

Instead of the overly complicated -L$(CURDIR), why don't you just use the equivalent -L. ?
Also, the Rtools suite uses MinGW which is not Cygwin so I'd avoid paths like /cygdrive/c/... as to MinGW this is still c:/....

Related

how to use a shared library which includes another shared library in c++

I have a c++ program, which contains two classes. one of them is using libssh and some of its functions and another one is for calculating cpu usage. there is a link of how I a built and added libssh:libssh's functions couldn't be found on qt my program works fine. now I want to build a .so library out of it to use in other programs. first I made two .o file like this:
gcc -c -fPIC info.cpp -o info.o
gcc -c -fPIC cpuusage.cpp -o cpuusage.o
and I made a .so from them:
gcc -shared -o libsmc.so info.o cpuusage.o
whenever I want to use libsmc.so, I include info.h, but the problem is that libssh functions cannot be found. I think I have to add libssh statically to my project. but I don't know how to!
Ps:I read this explanation :Using a shared library in another shared library , but this is for linking shared libraries that have been used in a program via command line, I don't wanna compile program with command line and want to link libraries constantly.
To build a C/C++ software using external libraries, I would really recommend to use a build system instead of typing commands manually.
The most used build system for C++ is CMake (https://cmake.org/), which is well supported by Qt, but there are many other build systems existing. Another is QMake, which is Qt's build system.
If you are using an IDE, like QtCreator or Microsoft Visual Studio, CMake is integrated as well. There are plenty of tutorials and example to use CMake for a project (e.g. https://mirkokiefer.com/cmake-by-example-f95eb47d45b1), even though the learning curve is not as steep as I would want.
But if you still want to use command line (or to debug the command line generated by CMake): When linking against a library, you need to:
Give the include path to the compiler, i.e. the path where the .h of the external library can be found. With gcc, this is done with -I, e.g. "-I/usr/lib/mylib/include".
Give the library folder and name to the linker, i.e. the path where to find the compiled library, as well as its name. With gcc, this is done with -L for the path and -l for the name. Check the gcc manual for more details about these commands.
And if you want to use CMake, then you can use the functions:
target_include_directories(..)
and
target_link_libraries(..)

pcl/pcl_config.h: No such file or directory

My environment is below.
・Operating System and version:windows 10 64bit
・Compiler:C:\msys64\mingw64\bin\g++.exe
・PCL Version:1.9.1
pcl_config.h not found as below error occurred when compiled under above env..
Certainly this header file is not included.
Let me know how to solve it.
PS C:\pcl\pcl\examples\common> g++ -o minmax -I ../../io/include -I ../../common/include .\example_get_max_min_coordinates.cpp
In file included from ../../common/include/pcl/PCLHeader.h:10,
from ../../common/include/pcl/point_cloud.h:47,
from ../../io/include/pcl/io/pcd_io.h:42,
from .\example_get_max_min_coordinates.cpp:2:
../../common/include/pcl/pcl_macros.h:64:10: fatal error: pcl/pcl_config.h: No such file or directory
#include
^~~~~~~~~~~~~~~~~~
compilation terminated.
Short answer
pcl_config.h is generated via pcl_config.h.in by the cmake tool. So it seems that compilation did not finish correctly.
Longer answer
Please make sure you have compiled the relevant modules of PCL (at least pcl-core) before proceeding
You might prefer a pre-built installation from releases or distributed by a package/source manager of your choice
PCL makes heavy use of other libraries and it is best to supply the dependencies (as mentioned below) via CMake or manually via the -I and -l options. If you provide the location of pcl_config.h, the compiler will complain about Eigen next.
The build instructions are available here. TL;DR: After satisfying the dependencies (cmake, c++ compiler, boost, eigen, flann, vtk and other depending on use-case), run the following commands
cd $PCL_SOURCE_DIR
mkdir -p build; cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j8
Feel free to use any build generator (like Ninja) or change build type to Debug or RelWithDebInfo as per your needs.

gcc not found by win-builder

I've built an R package which includes C/C++ code. I am now trying to test this package on win-builder. Unfortunately, the following error is returned in 00install.out:
* installing *source* package 'mypackage' ...
** libs
running 'src/Makefile.win' ...
/usr/bin/make --directory=lib/mylib/
gcc -g -Wall -fPIC -c mycode.c
make[1]: gcc: Command not found
make[1]: *** [mycode.o] Error 127
make: *** [mylib] Error 2
Warning: running command 'make --no-print-directory -f "Makefile.win"' had status 2
ERROR: compilation failed for package 'mypackage'
* removing 'd:/RCompile/CRANguest/R-release/lib/mypackage'
Trying with gcc, gcc.exe, and cc yielded similar results.
Accordingly, I set up a testing environment on a Windows virtual machine according to these instructions. Running R CMD INSTALL . on the code from the command line within this environment resulted in the code compiling and the package installing without issue. (Running R CMD build . also yielded no errors.)
What's up with win-builder, and how can I achieve compilation on it?
Or, more importantly, is being able to build the package on Windows sufficient, regardless of whether it worked on win-builder?
My Makefile.win is as follows:
export CCOMP = gcc
export CPPCOMP = c++
export ADD_CC_FLAGS = -O3
APP_DIR = ./apps/myapp
LIB_DIR = ./lib/mylib
.PHONY: all $(APP_DIR) $(LIB_DIR)
all: $(APP_DIR) $(LIB_DIR)
$(APP_DIR) $(LIB_DIR): mylib
$(MAKE) --directory=$#
$(APP_DIR): $(LIB_DIR) mylib
mylib:
$(MAKE) --directory=lib/mylib
Inserting echo %PATH% into the make file under the mylib target yielded:
Makefile.win:24: *** missing separator. Stop.
You get an obscure error here because you included a file Makefile.win.
But the semantics of make, if such a file is found, it will be used ... which is not what you want here. R builds its own Makefile.win and you are supposed to only supply a snippet to be included -- which must be called Makevars.win.
That is rule number one. Rules number two is to not included all the material you would include in a Makefile -- as you would clobber what R already brings to the table. All this is in Writing R Extensions but could of course be clearer.
My pragmatic suggestion: take a package you know and like which has a working R build in win-builder, and modify it. You can test locally should you have access to an R system with Rtools etc pp.
Edit from OP:
I needed to compile an executable which relied on several libraries. The library codes were in src/libs and the executable's code was in src/apps. I ensured that running make within each subdirectory worked and set src/apps/Makefile to use relative paths to pull in the results of src/libs. The only problem then, was getting the whole chain running. To do so, I created a file src/Makevars.win which had the following structure:
.PHONY: all myprogram sublib1 sublib2
all: sublib1 sublib2 myprogram
myprogram: sublib1 sublib2
#(cd apps/myprogram && $(MAKE) CXX="$(CXX)" CC="$(CC)" CFLAGS="$(CFLAGS) $(CPICFLAGS)" AR="$(AR)" RANLIB="$(RANLIB)")
sublib1:
#(cd lib/sublib1 && $(MAKE) CXX="$(CXX)" CC="$(CC)" CFLAGS="$(CFLAGS) $(CPICFLAGS)" AR="$(AR)" RANLIB="$(RANLIB)")
sublib2:
#(cd lib/sublib2 && $(MAKE) CXX="$(CXX)" CC="$(CC)" CFLAGS="$(CFLAGS) $(CPICFLAGS)" AR="$(AR)" RANLIB="$(RANLIB)")
As I understand it, Makevars.win gets embedded in a dynamically generated Makefile that R produces. So, $(CC) is actually referencing this hidden code.
(There are probably more clever ways to do this.)

Adding module to existing Qt5 installation from source

I have an existing Qt5.3.2 installation from tar.gz source files.
When attempting to compile VTK, which has optional Qt{4,5} interface, I was informed I don't have QtWebKitWidgets by ccmake.
I don't particularly want to reinstall Qt5 on top of the existing installation, for fear of breaking other things built against it.
Can I add to my current Qt5?
Would variants on
/path/to/configure -release -prefix $existingPrefix
make -module-qtwebkit
make install
or
/path/to/configure -release -prefix $newPrefix
make -module-qtwebkit
make install
cp -rf $newPrefix/CMake/QtWebKit (or similar path) $existingPrefix/CMake/
or as above, but with symlink, work?
Qt5.3 no longer includes QtWebKit, which should now be built separately.
The WebKit package can be downloaded from the Qt Downloads website, via the separate packages repository: link for 5.3.2
This can then be installed by appropriately setting environment variables such that the relevant (Qt5.3.2) qmake is first in the path, then from the expanded source directory, typing:
qmake
make -jN (with N make jobs)
(sudo, if appropriate) make install
The download is approximately 50MB.
Edit: It's also worth noting that if your Bison version is 3.x, then you might not be able to build the snapshot for QtWebKit. Instead download from the development repositories, to avoid an error looking something like: link to bug report
g++ -c [...] -o .obj/release-shared/generated/glslang_tab.o generated/glslang_tab.cpp
generated/glslang_tab.cpp: In function 'int yyparse(TParseContext*)':
generated/glslang_tab.cpp:1785:30: error: too few arguments to function 'int yylex(YYSTYPE*, void*)'
yychar = yylex (&yylval);
^
generated/glslang_tab.cpp:279:12: note: declared here
extern int yylex(YYSTYPE* yylval_param, void* yyscanner);

Building and installing an R package library with a jnilib extension

I'm building an R package and need to build a jni library for OSX (called myPackage.jnilib) as part of my build process and then have R's automatic installation mechanisms put it inside the libs directory of my package.
The problem is that R's default is to try and build an object called myPackage.so. I'd like to be able to customize this but can't see how.
I can get part of the way by subverting R's mechanisms using a phony "all" target in Makevars (described here) and then copying the file to the inst directory of my package. This is OK for my own local uses but generates headaches when trying to build universal binaries and isn't very portable. I'm currently preparing the package for CRAN so this method isn't likely to work.
I can see two potential solutions but haven't got either to work yet
Copy my library manually to the libs directory of my package during installation. Since this directory is created on the fly, how would I find out what it is from within Makevars or a configure script
The best solution: Tell R CMD SHLIB the name of my output file so I can use R's normal package mechanisms and let it copy the file to the right directory.
In case anyone else encounters this problem I'm posting my own workaround here.
I define targets in my Makevars and copy the libraries directly (ie answer 1). The variable R_LIBRARY_DIR provides the temporary location where the package is being built.
My Makevars now looks something like this
OBJECTS =
LIBSINSTDIR=$(R_LIBRARY_DIR)/myPackage/libs/
#ARCHFLAG is set in the configure script to i386 or ppc as appropriate
JNIINSTDIR=$(LIBSINSTDIR)/#ARCHFLAG#/
.PHONY: all
all: $(SHLIB) jnilib
jnilib: object1.o object2.o
$(CXX) -bundle $(JAVA_LIBS) $(JAVA_CPPFLAGS) -o libmyPackage.jnilib object1.o object2.o
mkdir -p $(JNIINSTDIR)
cp libmyPackage.jnilib $(JNIINSTDIR)

Resources