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.
Related
I'm trying to statically link glibc in order to run my application on an older OS, but when I use the -static flag I get "undefined reference" errors for other libraries I'm using that I don't get without using -static. How do I fix this issue?
My Makefile produces the following commands:
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c Utilities.cpp
gcc -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c ccvt.c
gcc -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c client.c
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c XML_Params.cpp
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c main.cpp
g++ -static -Wall -O3 -std=c++11 -L/storage/home/PA/libs/gsl -fopenmp -lgsl -lgslcblas -lm -L/storage/home/PA/libs/xerces -lxerces-c -o App main.o Utilities.o XML_Params.o ccvt.o client.o
After the last line I get a huge wall of errors complaining about undefined references to Xerces and gsl functions. However, if I remove the -static from the makefile, everything builds fine. What is the proper way to link these libraries when I'm using -static?
according to gcc manual:
-llibrary
It makes a difference where in the command you write this option; the
linker searches and processes libraries and object files in the order
they are specified. Thus, foo.o -lz bar.o searches library z after
file foo.o but before bar.o. If bar.o refers to functions in z,
those functions may not be loaded.
Move -lxerces after *.o might solve your problem.
I think you don't need to add -static except for the last line, correct me if i'm wrong.
I am trying to write a script that uses a library compiled with clang and another library compiled with G++, I get the following error:
ld.lld: error: undefined symbol: myFunction()
Which (according to this Difference between string and char[] types in C++) is apparently due to std::string meaning different things in different versions of G++ and clang.
Does this mean I have to rewrite the Makefile of my target library to use the same version of G++/Clang? Because that seems like an awful amount of effort just to link a prewritten library, and I think I must be missing something here.
More info
I am compiling v8_shell using ninja -C out/debug
defines = -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DMEMORY_TOOL_REPLACES_ALLOCATOR -DMEMORY_SANITIZER_INITIAL_SIZE -DADDRESS_SANITIZER -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DCR_CLANG_REVISION=\"353250-1\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DCOMPONENT_BUILD -D_LIBCPP_ABI_UNSTABLE -D_LIBCPP_ABI_VERSION=Cr -DCR_LIBCXX_REVISION=349080 -DCR_LIBCXXABI_REVISION=347903 -D_LIBCPP_ENABLE_NODISCARD -DCR_SYSROOT_HASH=e7c53f04bd88d29d075bfd1f62b073aeb69cbe09 -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -DENABLE_DISASSEMBLER -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_GDB_JIT_INTERFACE -DENABLE_MINOR_MC -DOBJECT_PRINT -DVERIFY_HEAP -DV8_TRACE_MAPS -DV8_ENABLE_ALLOCATION_TIMEOUT -DV8_ENABLE_FORCE_SLOW_PATH -DV8_INTL_SUPPORT -DENABLE_HANDLE_ZAPPING -DV8_USE_SNAPSHOT -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING -DV8_CHECK_MICROTASKS_SCOPES_CONSISTENCY -DV8_EMBEDDED_BUILTINS -DV8_ENABLE_CHECKS -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64 -DDEBUG -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DUSING_V8_SHARED -DV8_ENABLE_CHECKS -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -DUSING_V8_BASE_SHARED -DUSING_V8_PLATFORM_SHARED
include_dirs = -I../.. -Igen -I../.. -Igen -I../../include -Igen/include -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../include
cflags = -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -B../../third_party/binutils/Linux_x64/Release/bin -pthread -fcolor-diagnostics -fmerge-all-constants -Xclang -mllvm -Xclang -instcombine-lower-dbg-declare=0 -no-canonical-prefixes -fcomplete-member-pointers -m64 -march=x86-64 -Wall -Werror -Wextra -Wimplicit-fallthrough -Wthread-safety -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-ignored-pragma-optimize -fno-omit-frame-pointer -g2 -gsplit-dwarf -ggnu-pubnames -gcolumn-info -fsanitize=address -fsanitize-address-use-after-scope -fsanitize-blacklist=../../tools/memory/asan/blacklist.txt -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wmissing-field-initializers -Wextra-semi -Winconsistent-missing-override -Wunreachable-code -Wshorten-64-to-32 -O2 -fno-ident -fdata-sections -ffunction-sections
cflags_cc = -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -std=c++14 -fno-exceptions -fno-rtti -nostdinc++ -isystem../../buildtools/third_party/libc++/trunk/include -isystem../../buildtools/third_party/libc++abi/trunk/include --sysroot=../../build/linux/debian_sid_amd64-sysroot -fvisibility-inlines-hidden
label_name = v8_shell
target_out_dir = obj
target_output_name = v8_shell
build obj/v8_shell/shell.o: cxx ../../samples/shell.cc || obj/generate_bytecode_builtins_list.stamp obj/run_torque.stamp obj/v8_dump_build_config.stamp obj/src/inspector/protocol_generated_sources.stamp obj/third_party/icu/icudata.stamp
build ./v8_shell: link obj/v8_shell/shell.o obj/build/config/sanitizers/liboptions_sources.a | ./libv8.so.TOC ./libv8_libbase.so.TOC ./libv8_libplatform.so.TOC ./libicui18n.so.TOC ./libicuuc.so.TOC ./libc++.so.TOC || obj/build/win/default_exe_manifest.stamp obj/v8_dump_build_config.stamp obj/build/config/executable_deps.stamp
ldflags = -pie -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -fuse-ld=lld -Wl,--color-diagnostics -m64 -Werror -Wl,--gdb-index -rdynamic -nostdlib++ --sysroot=../../build/linux/debian_sid_amd64-sysroot -L../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -fsanitize=address -fsanitize-address-use-after-scope -pie -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,-rpath=\$$ORIGIN/. -Wl,-rpath-link=. -Wl,-O2 -Wl,--gc-sections -Wl,-u_sanitizer_options_link_helper -fsanitize=address -fsanitize-address-use-after-scope
libs = -L . -ldl -lpthread -lrt
output_extension =
output_dir = .
solibs = ./libtester.so ./libv8.so ./libv8_libbase.so ./libv8_libplatform.so ./libicui18n.so ./libicuuc.so ./libc++.so
Link to code is here:
https://github.com/v8/v8/blob/master/samples/shell.cc
All I have done is add a test library that returns a std::string and this is called from shell.cc.
This test library is compiled with
clang++ -shared -o libtester tester.cpp -fPIC -L . -lpthread
Which yields undefined symbol errors.
I can get it to compile by forcing libc++ that v8 seems to use, but then I get a whole host of core dumps and other errors at runtime, so I don't think thats a legitimate fix.
clang++ -shared -o libtester.so tester.cpp -fPIC -std=c++11 -L . -stdlib=libc++ -lpthread
Example code snippet:
tester.cpp
std::string myFunction() {
std::string newstring;
// do something
return newstring;
}
shell.cc
std::string test = myFunction();
cout << test;
Update please see these posts that document it further C++ Undefined symbol related to std::string in static lib
Can't link libFuzzer.a using clang with libc++
Theres no real answer apart from use libstdc++ rather than libc++ for everything, but thats not really an option to convert an entire project like v8 to libstdc++
The build recipe you use for V8 builds it with -D_LIBCPP_ABI_UNSTABLE -D_LIBCPP_ABI_VERSION=Cr -DCR_LIBCXX_REVISION=349080 -DCR_LIBCXXABI_REVISION=347903. According to libc++ ABI stability, these macros affect the library ABI. Your separate compilation uses just -stdlib=libc++, so it does not enable the incompatible ABI.
You might get better results if you use a different recipe for building V8, something that uses the system C++ standard library with its default (stable) ABI.
This is the solution for compiling v8 with libstdc++.
Type the following command
gn args out/stdc
Add the following arguments to the args file:
is_clang = true
use_custom_libcxx_for_host=false
use_custom_libcxx=false
libcxx_abi_unstable=false
Build with
ninja -C out/stdc
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```
I am on a complex project built in python2.7 that uses the PyDSTool package for analysis of dynamical system. PyDSTool provides two C-based integrators - Radau and Dopri - which I want to use to integrate my system of equations whose source is coded in a bunch of C/C++ files.
I have little control on the package, and when I instantiate the integrator, I can only add headers *.H files, source files (*.C, *.CPP) and pass the directories to include in the search path of the compiler as well as libraries to link to.
Since a consistent part of the code is based on C++11 I am passing to the compiler also the argument -std=C++11.
Eventually, /PyDSTool/Generators/mixins.py launch a setup command (line 185) which in turn runs the command build_ext from distutils to which all the above flags are appended.
For the sake of clarity: the flags that I am appending are:
compile options: '-I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c'
extra options: '-std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__'
The resulting compilation command as issued by PyDSTool reads:
error: Command "gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.c -o /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.o -std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__" failed with exit status 1
Once looking into the build.log file automatically generated by PyDSTool, it turns out that the exit status is due to the fact that the compiler does not see the C++ libraries that are in several routines/libs used by my code, e.g.
/usr/include/blitz/blitz.h:45:18: fatal error: string: No such file or directory
#include <string>
^
Compilation Terminated
Now, it is not a problem of my code, because if I compile my code as a standalone in python or through scipy.weave with the same compile and extra options pasted above, it works. It is a problem of making PyDSTool build the code within the integrator. As I am NOT practical with distutils and all gcc options I hope there is some expert here that could provide me with some insight. I suspect in fact that I am missing some options or whatever to pass to the compiler.
Just for the sake of completeness. The issue I pointed out above does not have an easy workaround. PyDSTool C-based integrators (i.e. Radau and Dopri) cannot be compiled with source code for the equations in C++ but only in C. So either you recast your code in plain C or try to edit PyDSTool integrators and recast them in C++. The first option is likely the only one currently possible (at least to some non-experts as who is writing).
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