When compiling Fortran code with f2py, gfortran.exe complains about '-mno-cygwin' option
I have checked all the answers about an analogous problem with gcc compiler and I have deleted -mno -Cygwin option from cygwincompiler.py (it was there only once). I am using python(x,y) version 2.7.10
f2py -c -m ex2lib ex2lib.f90 --fcompiler=gnu95 --compiler=mingw32
Reading fortran codes...
Reading file 'ex2lib.f90' (format:free)
Post-processing...
Block: ex2lib
Block: calcenergy
Block: calcforces
Block: calcenergyforces
Post-processing (stage 2)...
Building modules...
Building module "ex2lib"...
Constructing wrapper function "calcenergy"...
penergy = calcenergy(pos,[dim,natom])
Constructing wrapper function "calcforces"...
forces = calcforces(pos,[dim,natom])
Constructing wrapper function "calcenergyforces"...
penergy,forces = calcenergyforces(pos,[dim,natom])
Wrote C/API module "ex2lib" to file "c:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\ex2libmodule.c"
adding 'c:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\fortranobject.c' to sources.
adding 'c:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7' to include_dirs.
copying C:\Python27\lib\site-packages\numpy\f2py\src\fortranobject.c -> c:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7
copying C:\Python27\lib\site-packages\numpy\f2py\src\fortranobject.h -> c:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7
build_src: building npy-pkg config files
running build_ext
Cannot build msvcr library: "msvcr90d.dll" not found
customize Mingw32CCompiler
customize Mingw32CCompiler using build_ext
customize Gnu95FCompiler
Found executable C:\MinGW\bin\gfortran.exe
Found executable C:\MinGW\bin\gfortran.exe
customize Gnu95FCompiler using build_ext
building 'ex2lib' extension
compiling C sources
C compiler: gcc -O2 -Wall -Wstrict-prototypes
creating c:\users\roman\appdata\local\temp\tmp5wnlgh\Release
creating c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users
creating c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman
creating c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata
creating c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local
creating c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp
creating c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp\tmp5wnlgh
creating c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7
compile options: '-DNPY_MINGW_USE_CUSTOM_MSVCR -D__MSVCRT_VERSION__=0x0900 -Ic:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7 -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC -c'
gcc -O2 -Wall -Wstrict-prototypes -DNPY_MINGW_USE_CUSTOM_MSVCR -D__MSVCRT_VERSION__=0x0900 -Ic:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7 -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC -c c:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\fortranobject.c -o c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\fortranobject.o
Found executable C:\MinGW\bin\gcc.exe
gcc -O2 -Wall -Wstrict-prototypes -DNPY_MINGW_USE_CUSTOM_MSVCR -D__MSVCRT_VERSION__=0x0900 -Ic:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7 -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC -c c:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\ex2libmodule.c -o c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\ex2libmodule.o
compiling Fortran sources
Fortran f77 compiler: C:\MinGW\bin\gfortran.exe -Wall -g -ffixed-form -fno-second-underscore -O2 -funroll-loops
Fortran f90 compiler: C:\MinGW\bin\gfortran.exe -Wall -g -fno-second-underscore -O2 -funroll-loops
Fortran fix compiler: C:\MinGW\bin\gfortran.exe -Wall -g -ffixed-form -fno-second-underscore -Wall -g -fno-second-underscore -O2 -funroll-loops
compile options: '-Ic:\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7 -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC -c'
gfortran.exe:f90: ex2lib.f90
C:\MinGW\bin\gfortran.exe -Wall -g -mno-cygwin -Wall -g -mno-cygwin -shared c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\ex2libmodule.o c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\fortranobject.o c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\ex2lib.o -Lc:\mingw\lib\gcc\mingw32\6.3.0 -LC:\Python27\libs -LC:\Python27\PCbuild -lpython27 -lgfortran -o .\ex2lib.pyd
gfortran.exe: error: unrecognized command line option '-mno-cygwin'; did you mean '-mno-clwb'?
gfortran.exe: error: unrecognized command line option '-mno-cygwin'; did you mean '-mno-clwb'?
error: Command "C:\MinGW\bin\gfortran.exe -Wall -g -mno-cygwin -Wall -g -mno-cygwin -shared c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\ex2libmodule.o c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\users\roman\appdata\local\temp\tmp5wnlgh\src.win32-2.7\fortranobject.o c:\users\roman\appdata\local\temp\tmp5wnlgh\Release\ex2lib.o -Lc:\mingw\lib\gcc\mingw32\6.3.0 -LC:\Python27\libs -LC:\Python27\PCbuild -lpython27 -lgfortran -o .\ex2lib.pyd" failed with exit status 1```
Related
I was building some Cython extensions, and have to link it against a static library (it has CUDA code in them, so have to be static):
running build_ext
building 'k3lib' extension
gcc -pthread -B /home/kelvin/anaconda3/envs/torch/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/kelvin/repos/tools/include -I/home/kelvin/anaconda3/envs/torch/include/python3.8 -c main.cpp -o build/temp.linux-x86_64-3.8/main.o -O3 -march=native
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
g++ -pthread -shared -B /home/kelvin/anaconda3/envs/torch/compiler_compat -L/home/kelvin/anaconda3/envs/torch/lib -Wl,-rpath=/home/kelvin/anaconda3/envs/torch/lib -Wl,--no-as-needed -Wl,--sysroot=/ build/temp.linux-x86_64-3.8/main.o /home/kelvin/repos/tools/include/libk2.a -L/home/kelvin/repos/tools/include -lk2 -o build/lib.linux-x86_64-3.8/k3lib.cpython-38-x86_64-linux-gnu.so -static -Wl,-Bstatic -flinker-output=exec
However, Cython's g++ compile command includes the options -shared -fPIC by default. I tried a number of options at the end of the command via this setup file (the static library is at $(LOCAL_INCLUDE)/libk2.a):
includes = [os.getenv("LOCAL_INCLUDE")]
ext_modules = [
Extension("k3lib", sources=["main.pyx"],
libraries=["k2"], include_dirs=includes, library_dirs=includes, language="c++",
extra_compile_args=["-O3", "-march=native"], extra_objects=[f"{includes[0]}/libk2.a"],
extra_link_args=['-static', '-Wl,-Bstatic', '-flinker-output=exec'])
]
#extra_objects=[f"{includes[0]}/libk2.a"]
#extra_link_args=['-static']
setup(name="k3lib", ext_modules=cythonize(ext_modules, language_level="3"))
Still, g++ thinks that I want to build a shared library, and thus the error message. Is there a way to override the -shared option? I'm planning to go into Cython's files and edit them myself, but was wondering is there a simpler way?
Context: I was following this question on SO but can't replicate their success.
I want to build mesa3d source code for some reason. I follow the guide on https://mesa3d.org/install.html and the build environment is fedora31 and gcc9.2, but there are some build error when I trying to build the code with running ninja install.
FAILED: src/mesa/drivers/dri/r200/58cd8d4##r200#sta/radeon_buffer_objects.c.o
cc -Isrc/mesa/drivers/dri/r200/58cd8d4##r200#sta -Isrc/mesa/drivers/dri/r200 -I../src/mesa/drivers/dri/r200 -Iinclude -I../include -Isrc -I../src -Isrc/mapi -I../src/mapi -Isrc/mesa -I../src/mesa -I../src/gallium/include -Isrc/gallium/auxiliary -I../src/gallium/auxiliary -Isrc/mesa/drivers/dri/common -I../src/mesa/drivers/dri/common -Isrc/util -I../src/util -I../src/mesa/drivers/dri/r200/server -Isrc/util/xmlpool -I/usr/include/libdrm -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O2 -g -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="20.0.0-devel"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/issues"' -DUSE_ELF_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_UINT128 -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_EXECINFO_H -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_POSIX_MEMALIGN -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="9.0.0"' -DHAVE_VALGRIND -DHAVE_WAYLAND_PLATFORM -DWL_HIDE_DEPRECATED -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=empty-body -Werror=incompatible-pointer-types -Wno-missing-field-initializers -Wno-format-truncation -fno-math-errno -fno-trapping-math -Werror=format -Wformat-security -fPIC -fvisibility=hidden -DRADEON_R200 -MD -MQ 'src/mesa/drivers/dri/r200/58cd8d4##r200#sta/radeon_buffer_objects.c.o' -MF 'src/mesa/drivers/dri/r200/58cd8d4##r200#sta/radeon_buffer_objects.c.o.d' -o 'src/mesa/drivers/dri/r200/58cd8d4##r200#sta/radeon_buffer_objects.c.o' -c ../src/mesa/drivers/dri/r200/radeon_buffer_objects.c
../src/mesa/drivers/dri/r200/radeon_buffer_objects.c:1:1: error: expected identifier or '(' before '.' token
1 | ../radeon/radeon_buffer_objects.c
| ^
Then I check the radeon_buffer_objects.c, and this file just have one file path in it.
../radeon/radeon_buffer_objects.c
I'm not very familier with gcc and clang. What is that mean? And how can I resolve this build error?
As AnthonySottile's comment said, this error is about the symbol link support. I have cloned this repo to windows before and upload to my own git server. And the error occured when I trying to build the source code from my git.
I try to clone the repo from mesa3d.org, and the issue resolved.
Thanks for the help, guys.
I have a package I'm writing in R that has a boatload of complicated C++ code which takes a while to compile.
When I change the code, I'd like to quickly rebuild the package so I can test it. However, R CMD build seems to start from scratch each time, rather than using my code's makefiles to do only what is needed.
Is there a way to quickly do repeated builds of a package in R for testing?
I am a little overdue a short blog post on this, but I mentioned it a couple of times before: use ccache. It helps dramatically when the files don't change (ie when you just alter help pages), or when few files changes. Caching is a very clever trick, and package is robust.
On Ubuntu/Debian: sudo apt-get install ccache followed by e.g. this in your ~/.R/Makevars:
VER=
CCACHE=ccache
#CCACHE=
CC=$(CCACHE) gcc$(VER)
CXX=$(CCACHE) g++$(VER)
CXX11=$(CCACHE) g++$(VER)
CXX14=$(CCACHE) g++$(VER)
That also allows to switch between g++ versions. Changing it to clang++ is left as an exercise to the reader ;-)
Besides this, see the options to R CMD build and R CMD INSTALL to skip vignette and/or manual building to further speed up re-builds.
Illustration: Here is re-install of Rcpp itself (fresh from a git pull) where the first installation takes 21.9 seconds on my (decent) machine at work, the second then only takes 1.4 seconds thanks to ccache:
~/git/rcpp(master)$ time R CMD INSTALL .
* installing to library ‘/usr/local/lib/R/site-library’
* installing *source* package ‘Rcpp’ ...
** libs
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c Date.cpp -o Date.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c Module.cpp -o Module.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c Rcpp_init.cpp -o Rcpp_init.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c api.cpp -o api.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c attributes.cpp -o attributes.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c barrier.cpp -o barrier.o
g++ -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o Rcpp.so Date.o Module.o Rcpp_init.o api.o attributes.o barrier.o -L/usr/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/Rcpp/libs
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (Rcpp)
real 0m21.917s
user 0m21.388s
sys 0m2.304s
~/git/rcpp(master)$ ./cleanup
~/git/rcpp(master)$ time R CMD INSTALL .
* installing to library ‘/usr/local/lib/R/site-library’
* installing *source* package ‘Rcpp’ ...
** libs
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c Date.cpp -o Date.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c Module.cpp -o Module.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c Rcpp_init.cpp -o Rcpp_init.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c api.cpp -o api.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c attributes.cpp -o attributes.o
ccache g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/ -fpic -g -O3 -Wall -pipe -pedantic -Wextra -Wno-empty-body -Wno-unused -c barrier.cpp -o barrier.o
g++ -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o Rcpp.so Date.o Module.o Rcpp_init.o api.o attributes.o barrier.o -L/usr/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/Rcpp/libs
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (Rcpp)
real 0m1.444s
user 0m1.380s
sys 0m1.452s
~/git/rcpp(master)$
Dirk's answer above pointed me in the right direction, but was insufficient. Since he has requested that I not append the final steps I required, I do so here.
My question could not have been answered without the following.
Dirk's answer did not work off the bat for me. If compilation still seems slow to you, try running:
ccache -s
The result will look a little like this
cache directory /home/myuser/.ccache
primary config /home/myuser/.ccache/ccache.conf
secondary config (readonly) /etc/ccache.conf
cache hit (direct) 0
cache hit (preprocessed) 0
cache miss 989
cache hit rate 0 %
called for link 12
preprocessor error 12
cleanups performed 16
files in cache 177
cache size 31.1 MB
max cache size 5.0 GB
Note that cache isn't getting hit, which means ccache isn't doing anything.
You can use:
export CCACHE_LOGFILE=ccache.log
R CMD build .
to do some debugging, though this wasn't helpful for me.
What fixed things was to run:
export CCACHE_NOHASHDIR=true
R CMD build .
As it turns out, ccache sometimes takes the location of a file into account. R CMD build . appears to build in a temporary directory, so the location of the files was changing each time.
I'm currently working on an R package which uses C++ code and includes external libraries (dlib, boost and an optimization library developed in the group). We're using Rcpp to integrate R and C++, but the problem is the package always fails to compile, and none of the similar questions I've found out there have worked for me.
The report generated by R CMD check is:
* installing *source* package 'IRTppExperimental' ...
** libs
*** arch - i386
c:/Rtools/mingw_32/bin/g++ -std=c++0x -I"C:/PROGRA~1/R/R-33~1.1/include" -DNDEBUG -I"C:/Users/Camilo/Documents/R/win-library/3.3/Rcpp/include" -I"d:/Compiler/gcc-4.9.3/local330/include" -I../src/include -O2 -Wall -mtune=core2 -c RcppExports.cpp -o RcppExports.o
c:/Rtools/mingw_32/bin/g++ -std=c++0x -I"C:/PROGRA~1/R/R-33~1.1/include" -DNDEBUG -I"C:/Users/Camilo/Documents/R/win-library/3.3/Rcpp/include" -I"d:/Compiler/gcc-4.9.3/local330/include" -I../src/include -O2 -Wall -mtune=core2 -c rcpp_hello_world.cpp -o rcpp_hello_world.o
c:/Rtools/mingw_32/bin/g++ -std=c++0x -I"C:/PROGRA~1/R/R-33~1.1/include" -DNDEBUG -I"C:/Users/Camilo/Documents/R/win-library/3.3/Rcpp/include" -I"d:/Compiler/gcc-4.9.3/local330/include" -I../src/include -O2 -Wall -mtune=core2 -c test_multi.cpp -o test_multi.o
c:/Rtools/mingw_32/bin/g++ -shared -s -static-libgcc -o IRTppExperimental.dll tmp.def RcppExports.o rcpp_hello_world.o test_multi.o -LC:/PROGRA~1/R/R-33~1.1/bin/i386 -lRlapack -LC:/PROGRA~1/R/R-33~1.1/bin/i386 -lRblas IRTppExperimental.dll -L../src/include -Ld:/Compiler/gcc-4.9.3/local330/lib/i386 -Ld:/Compiler/gcc-4.9.3/local330/lib -LC:/PROGRA~1/R/R-33~1.1/bin/i386 -lR
g++.exe: error: IRTppExperimental.dll: No such file or directory
no DLL was created
ERROR: compilation failed for package 'IRTppExperimental'
* removing 'C:/Users/Camilo/Documents/UNAL/MIRT/Tests/Temps/IRTppExperimental.Rcheck/IRTppExperimental'
And the Makevars/Makevars.win files are as follows:
INCFOLDER = ../src/include
PKG_LIBS += $(LAPACK_LIBS) $(BLAS_LIBS) $(FPICFLAGS) $(SHLIB)
PKG_LIBS += -L$(INCFOLDER)
PKG_CXXFLAGS+=-I$(INCFOLDER)
CXXFLAGS+="-fno-stack-protector"
CXX_STD = CXX11
Lastly, the NAMESPACE file reads:
exportPattern("^[[:alpha:]]+")
importFrom(Rcpp,sourceCpp)
useDynLib(IRTppExperimental)
All the c++ source files are inside the src folder, including the external libraries. The package was created using the Rcpp.package.skeleton function, and used the compileAtributes function to create the RcppExports source files.
EDIT: As pointed out by Coatless, here is github link of the project: https://github.com/SICSresearch/IRTpp/tree/Uni-Multi-Merging
When compiling my code I run into an issue as follows:
io.cpp:21: undefined reference to `PQconnectdb'
as well as all other instances of missing postgres function calls occurring in my code. Obviously this is a linking problem, I'm just not sure what the link issue is.
I'm compiling with the following:
mpiCC -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ decisioning_mpi.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ io.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ calculations.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ rules.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ Instrument.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ Backtest_Parameter_CPO.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ Backtest_Trade_CPO.cpp
g++ -c -O2 -g -Wall -Werror -I /usr/include/postgresql/ Data_Bar.cpp
mpiCC -o decisioning_mpi -O2 -g -Wall -Werror -L/usr/lib -lm -lpq decisioning_mpi.o
io.o calculations.o rules.o Instrument.o Backtest_Parameter_CPO.o Backtest_Trade_CPO.o Data_Bar.o
It should be noted that this is the correct directory for libpq-fe.h and that I'm linking pq, so I'm not exactly sure why the postgres functions aren't linking correctly. I'm running Ubuntu 12.04 and installed psql (PostgreSQL) 9.1.6 from synaptic. As well I'll short circuit this, I am using #include "libpq-fe.h".
Any ideas on how I can get this linking issue resolved?
put -L/usr/lib/ -lm -lpq in the end of link command, the linker can then find the symbols
mpiCC -o decisioning_mpi -O2 -g -Wall -Werror decisioning_mpi.o io.o \
calculations.o rules.o Instrument.o Backtest_Parameter_CPO.o \
Backtest_Trade_CPO.o Data_Bar.o -L/usr/lib -lm -lpq
GCC Link Reference:
http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html