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.)
Related
I need help with installing a software.
In general: I try to install PostGIS on a cluster (CentOS) and do not have admin rights. There is a sqlite3 installation (connected to the error), but this seems corrupt. My own one usually works and has (also by install-process) been used previously.
I cannot use yum.
In detail:
For having the MakeFiles build I set flags as I believe to possibly need them:
./configure --prefix="$HOME/.local" CFLAGS="-I$HOME/.local/include" LDFLAGS="-L$HOME/.local/lib" LT_SYS_LIBRARY_PATH="$HOME/.local/lib" LIBS="-L$HOME/.local/lib" SQLITE3_CFLAGS="-I$HOME/.local/include" SQLITE3_LIBS="-L$HOME/.local/lib"
But the following error is thrown when running make:
/usr/bin/sed: can't read /usr/local/lib/libsqlite3.la: No such file or directory
libtool: error: '/usr/local/lib/libsqlite3.la' is not a valid libtool archive
Right after (but I don't see the connection):
libtool: link: ranlib .libs/liblwgeom.a
If I run make again, it jumps that directory. But gets stuck with a similar error (which is not jumped by running make another time):
/bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes -std=gnu99 -I<exp. $HOME>/.local/include -fno-math-errno -fno-signed-zeros -fPIC -DPIC -I../rt_core -I../../liblwgeom -I<exp. $HOME>/.local/include -I/usr/include/gdal -I<exp. $HOME>/.local/include ../rt_core/librtcore.a raster2pgsql.o -L<exp. $HOME>/.local/lib -static ../../liblwgeom/liblwgeom.la -L/usr/lib64 -lgdal -L<exp. $HOME>/.local/lib -lgeos_c -lc -lm -o raster2pgsql
libtool: error: cannot find the library '/usr/local/lib/libsqlite3.la' or unhandled argument '/usr/local/lib/libsqlite3.la'
I don't get why libtool searches in '/usr/local/lib/'. I didn't find that hardcoded in libtool or the MakeFiles. I'm clueless - and this is above my skill (apperently).
Can you help me?
One of the dependencies (proj) linked in its .la file to the malicious sqlite3 version. Reinstalling this dependency solved the issue.
What would help in similar cases would be to search the 'wrong path' in the dependencies:
find <deps lib dir> -type f -exec grep -l "<wrong path>" {} +
Kudos go to https://stackoverflow.com/a/62500481/14339502 who stated the valuable hint that "it seems like you have some other .la file that references it".
I have installed the pNaCl SDK and have run the command "make serve", as instructed to by the website https://developers.google.com/native-client/dev/devguide/tutorial/tutorial-part1 into my console, it does not run any server and produces the error message:
C:\Users\USERNAME\Documents\nacl_sdk\nacl_sdk\pepper_33\getting_started>make serv
e
C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_33/tools/make -C part1 all
process_begin: CreateProcess(NULL, python C:/Users/USERNAME/Documents/nacl_sdk/na
cl_sdk/pepper_33/tools/getos.py, ...) failed.
make[1]: Entering directory 'C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper
_33/getting_started/part1'
make[1]: Makefile:27: pipe: No error
C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_33/toolchain/_pnacl/bin/pnac
l-clang++ -o hello_tutorial.bc hello_tutorial.cc -O2 -IC:/Users/USERNAME/Document
s/nacl_sdk/nacl_sdk/pepper_33/include -LC:/Users/USERNAME/Documents/nacl_sdk/nacl
_sdk/pepper_33/lib/pnacl/Release -lppapi_cpp -lppapi
process_begin: CreateProcess(NULL, C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/
pepper_33/toolchain/_pnacl/bin/pnacl-clang++ -o hello_tutorial.bc hello_tutorial
.cc -O2 -IC:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_33/include -LC:/Us
ers/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_33/lib/pnacl/Release -lppapi_cpp
-lppapi, ...) failed.
make (e=2): The system cannot find the file specified.
Makefile:50: recipe for target 'hello_tutorial.bc' failed
make[1]: *** [hello_tutorial.bc] Error 2
make[1]: Leaving directory 'C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_
33/getting_started/part1'
Makefile:46: recipe for target 'part1_ALL_TARGET' failed
make: *** [part1_ALL_TARGET] Error 2
My username is inserted in the place of USERNAME.
Any ideas what is going on?
I looks like perhaps python is not present in you PATH? Can you run "python" on the command line? What does "where python" produce?
I'm somewhere surprised since python is required to install the SDK in the first place. I've opened a ticket to handle this failure mode:
https://code.google.com/p/chromium/issues/detail?id=348139
I solved this, had the same issues, what i did was (my setup):
It seems compile script doesn't like paths with spaces, like: "C:\Documents and ...".
Make sure python path is at environment variables. "C:\Python27"
Put nacl_sdk folder in "C:\stationary".
Put custom environment variable NACL_SDK_ROOT to "C:\stationary\nacl_sdk\pepper_34".
There i did immediate variable assignee.
A. "cd C:\stationary\nacl_sdk\pepper_34\getting_started".
B. "set NACL_SDK_ROOT C:\stationary\nacl_sdk\pepper_34". This must point to the pepper version you want to build against,
C. "make serve".
And that's it! Works, compiled!
I have encountered and solved the same issue. using comment on old post. I tried building one of the other examples and they seem to work while the getting started one doesn't.
"You will have a hard time building those ppapi tests. I suggest trying to build one of the examples provided with the SDK. If you really need to build that test (it isn't an example) you will need to use clang (another C/C++ toolchain). However, from a cursory look, those tests aren't actually built in NaCl, nor do they generate a PPAPI plugin. I have never gotten clang working on Windows, but it is apparently possible. See clang.llvm.org/get_started.html for instructions using Visual Studio. I would probably use MinGW instead, but I can't find decent instructions for that. – DRayX Oct 21 '13 at 16:08 "
I'm trying to use this sqlite extension to calculate stdev in Sqlite dbs, on Linux, I use this command to compile the lib
gcc -fPIC -lm -shared extension-functions.c -o libsqlitefunctions.so
but seems that the .load command is not in the sqlite .help command list, and I got error:
unknown command or invalid arguments: "load". Enter ".help" for help
Same thing happens when I use the command:
sqlite> SELECT load_extension('./libsqlitefunctions.so');
SQL error: no such function: load_extension
I tried to use this instruction to compile sqlite:
0. untar latest sqlite3 source code in a new directory
1. cd to the newly untarred sqlite directory
2. Comment out the line in Makefile.in to enable loadable extensions:
# TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1
3. ./configure LIBS=-ldl && make sqlite3
4. export LD_LIBRARY_PATH="`pwd`:$LD_LIBRARY_PATH"
5. gcc -I`pwd` -shared src/test_loadext.c -o half.so
6. ./sqlite3
But couldn't find the line "TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1" in the newest Sqlite source code.
It looks like configure was updated but not the documentation. Try
./configure --enable-dynamic-extensions
The reference is the configure source code. Digging further, it looks like the dynamic extensions are enabled by default. From README:
The generic installation instructions for autoconf/automake are found
in the INSTALL file.
The following SQLite specific boolean options are supported:
--enable-readline use readline in shell tool [default=yes]
--enable-threadsafe build a thread-safe library [default=yes]
--enable-dynamic-extensions support loadable extensions [default=yes]
So I think load is present. It's the second part of the error invalid arguments that's the problem.
The cause seems to be that you're using Linux instructions. That won't work. Macs don't generally have .so files, which is what your compilation command is generating.
The method of compiling and loading a Mac dynamic library, loadable as an extension, is at this location. The compile command is going to look something like
gcc -bundle -fPIC -I/path-to-sqlite/sqlite3 -o filename.sqlext filename.c
Note the -bundle and -fPIC that are important for dynamic loading, but which you were missing. The resulting filename will be filename.sqlext, so use that in your path.
It may be worth noting that you may get a "missing symbols" error when you load the library - this is due to the fact that the -lm flag needs to be at the end of the compile command thus:
gcc -fPIC -shared extension-functions.c -o libsqlitefunctions.so -lm
Regards Fat jonnie
I am trying to do a static build of Qt (4.8.1) using mingw32-make (gcc 4.7.0) so that I can statically link my application for the sake of ease of use/delivery.
I keep getting a strange error from mingw32-make, though, which I do not understand.
../3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalObject.h:270:103: warning: control reaches end of non-void function [-Wreturn-type]
Makefile.Release:2033: recipe for target 'obj/release/JSBase.o' failed
mingw32-make[2]: *** [obj/release/JSBase.o] Error 1
mingw32-make[2]: Leaving directory 'C:/StaticQt/qt/src/script'
Makefile:34: recipe for target 'release' failed
mingw32-make[1]: *** [release] Error 2
mingw32-make[1]: Leaving directory 'C:/StaticQt/qt/src/script'
Makefile:1360: recipe for target 'sub-script-sub_src_target_ordered' failed
mingw32-make: *** [sub-script-sub_src_target_ordered] Error 2
Looking in the associated Makefile.Release file, on the indicated lines, I find these:
Makefile.Release 2033: $(CXX) -c $(CXXFLAGS) $(INCPATH) -o obj/release/JSBase.o ../3rdparty/javascriptcore/JavaScriptCore/API/JSBase.cpp
Makefile.Release 1360: $(CXX) -c $(CXXFLAGS) $(INCPATH) -o obj/release/pcre_compile.o ../3rdparty/javascriptcore/JavaScriptCore/pcre/pcre_compile.cpp
Makefile 34: $(MAKE) -f $(MAKEFILE).Release
I really understand very little about makefiles, so haven't a clue what these lines mean. Any help with this would be very much appreciated.
EDIT: it just occured to me it may be useful for people to know the commandline arguments I used... Well, I followed this guide: http://www.qtcentre.org/wiki/index.php?title=Building_static_Qt_on_Windows
There were syntax errors in the code for some reason. Somebody must've updated the Qt Git with the wrong code just before I downloaded it. I got the code from elsewhere and managed to get it to compile using visual studio's nmake instead... turned out it didn't really matter whether I used mingw or vc2008.
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:/....