I am wrapping a small c++ program in R by using Rcpp, and I checked beforehand that the c++ code is compiling directly with g++ 4.8.4 without warnings or errors. There are no external librairies, only STL is used.
When I compile my package in RStudio with devtools, I obtain the following error:
Updating PerseusR documentation
Loading PerseusR
Error in dyn.load(dllfile) :
unable to load shared object '/home/leonid/Documents/Programmation/PerseusR project/PerseusR/src/PerseusR.so':
/home/leonid/Documents/Programmation/PerseusR project/PerseusR/src/PerseusR.so: undefined symbol: _Z9lexicoPoslllRSt6vectorIlSaIlEE
Calls: suppressPackageStartupMessages ... -> load_all -> load_dll -> library.dynam2 -> dyn.load
Execution halted
Exited with status 1.
It seems that the compilation is fine and there is a problem with the loading of some dynamic libraries.
In the undefined symbol, lexicoPos is the name of a function in the c++ code.
Any ideas on how to solve this problem?
If your home-grown attempt fails, I suggest you start with a created example: Call Rcpp.package.skeleton() and compare all the files it creates with what you have.
Maybe you forgot the required line in NAMESPACE, maybe it is something -- we cannot tell from the information you supplied.
Related
I'm trying to compile a c++ mex function that I created according to the specifications given by mathworks here (Create a C++ MEX Source File). However, after following the steps of the answer in this thread to link Eclipse 4.4.2 and Matlab R2015a in a linux enviroment (old but the only one I've found about it), I get the following error:
undefined reference to `get_function_ptr' mpi_pevd_mex_f line 79, external location: C:\Program Files\MATLAB\R2021a\extern\include\MatlabDataArray\detail\ExceptionHelpers.hpp C/C++ Problem
I don't know what else is missing. I've been trying to find a solution, but nothing useful so far.
Thank you for your help.
I have found the problem. Apparently, I needed to add additional libraries to those detailed in most of the posts related to MEX files, i.e. libmex/ libmat/libmx.
Making use of the verbose mode in Matlab (mex -v MexFunction.cpp), I realized that these libraries were missing: libmwlapack, m, libmwblas, libMatlabEngine, libMatlabDataArray. After adding them, the error disappeared.
I'm trying to run the example "Scale_Space_Surface_Reconstruction_3" from CGAL library on CodeBlocks IDE on Ubuntu platform, as it would be nice
to have the IDE support for code completion and a more automatic configuration process.
I managed to successfully execute it by compiling it with cmake on the terminal window.
However, on CodeBlocks, after creating a new project and copying the code from the example, I get the following error:
/usr/local/include/CGAL/Scale_Space_Reconstruction_3/Scale_Space_Surface_Reconstruction_Impl_3.h:165:23: error: variable or field 'pca' declared void
Approximation pca( _nn[i]);
By looking inside the code, I found out that this is due to an undefined Macro CGAL_EIGEN3_ENABLED. As my experiment shows, if I define the macro at
pre-processing time, I do not get the same error. That is because, by defining the macro, the type definition Default::Get< wA,void>::type, becomes
Default::Get< wA, Weighted_PCA_approximation_3<Gt>>::type, and the compiler does not complain any more.
Unfortunately, as a deserved prize for messing with things I do not really understand, I get a segmentation fault at runtime.
How should I change the compiler options of codeBlocks to make the compilation succeed, and the executable run successfully?
I have the following include paths:
/usr/local/lib/CGAL/ /usr/local/include /usr/include /usr/include/eigen3.
I also included the following libraries:
libCGAL.so, libCGAL_Core.so, libCGAL_ImageIO.so, libgmp.so, libmpfr.so, libtbb.so, libtbbmalloc.so, libtbbmalloc_proxy.so
I have an application which uses a class Foo from an .so shared library. I've come across a problem where at runtime it prints
<appname>: symbol lookup error: <appname>: undefined symbol: <mangled_Foo_symbol_name>
Now, it turned out that the unmangled symbol was for the constructor of the class Foo, and the problem was simply that an old version of the library was loaded, which didn't contain Foo yet.
My question isn't about resolving the error (that's obviously to use the correct library), but why it appears at runtime instead of at time of load / startup.
The line of code causing the error just instantiates an object of class Foo, so I'm not using anything like dlopen here, at least not explicitly / to my knowledge.
In contrast, if I remove the whole library from the load search path, I get this error at startup:
<appname>: error while loading shared libraries: libname.so.2: cannot open shared object file: No such file or directory
When the wrong version of gcc / libstdc++ is on the load path, an error also appears at starup:
<appname>: /path/to/gcc-4.8.0/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by <appname>)
This "fail fast" behavior is much more desirable, I don't want to run my application for quite awhile first, until I finally realize it's using the wrong library.
What causes the load error to appear at runtime and how can I make it appear immediately?
From the man page of ld.so:
ENVIRONMENT
LD_BIND_NOW (libc5; glibc since 2.1.1) If set to a nonempty string, causes the dynamic linker to resolve all symbols at program startup instead of deferring function call resolution to the point when they are first referenced. This is useful when using a debugger.
LD_WARN (ELF only)(glibc since 2.1.3) If set to a nonempty string, warn about unresolved symbols.
I think you can not statically link .so library. If you want to avoid load/run time errors you have to use all static libraries (.a). If you do not have static version of library and source then try to find some statifier. After googling I find few statifiers but do not know how do they work so leaving that part up to you.
When following this tutorial I'm getting the following errors: undefined reference to '__unwind_resume' and undefined reference to '__gxx_personality_v0'
The file producing these undefined reference error's is libboost_system-mgw47-mt-1_51.a. I have already tried the following fixes to no avail:
Forcing Code::blocks to use g++ instead of gcc.
Result: No change
Adding-lstdc++ to the list of libraries the linker links to.
Result: 39 more errors in addition to the __unwind_resume and __gxx_personality_v0 undefined reference errors.
Installing the latest MingW and pointing my compiler to use it instead of its own version
Result: Compiler errors now exceeds max value :(
image2 http://s24.postimage.org/3u6tik4dh/moreerrors2.jpg
Any help troubleshooting these errors is appreciated, I really want to get this thing working.
I found part of the solution, I got the compiler to create an executable file, but it currently throws OGRE::filenotfoundexception and terminates. I did this by downloading boost_1_53_0 and building libboost_system-mgw47-mt-1-53.a and linking to that instead of the other one, then it gave me the error on startup "the procedure entry point __gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll." So to work around that I went to orwell's mingw folder and found that libstdc++-6.dll in that folder was around 800 KB in size and the one codeblocks was using was 5 mb, I switched them out to see if it worked and it got the executable running now but it throws said exception and terminates.
EDIT1: Strangely enough simply adding a blank file called resources.cfg (the file that caused the exception) causes the program to run but now an Ogre windows appears asking for a rendering system
EDIT2: After realizing I'm supposed to copy everything from ogre's bin/release directory to my executable files directory (and the media directory to 2 folders up from my executables directory) I did that and everything finally worked perfectly!
I have Core static library, a few Component static libraries that relays on the Core one, and then there is an App that links against both Core and Component libraries. My App can link both against Core and Component as long as Component don't uses classes from Core (App uses classes from Core).
I got the following error in both armv6 and armv7 versions. So my problem is not the very popular linking issue that everyone has.
ld: symbol(s) not found for architecture armv6
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I added reference to Core in Component and even added it in "Link Binary With Libraries" which shouldn't be necessary for static lib.
Since I start having this issue I start doubting my design... It probably makes more sense in dynamically linking environment but still it should be doable in static one, especially since this already works under Windows with MSVC compilers.
Edit:
I made some progress! Although I still don't know where to go with it.
Here is my setup:
Core has a class cResourceManager that has a templated method GetResource<T>(int id)
Core also has class cResource
Component has class cMesh that inherits cResource
Here are some tests:
If I try from App to call rm->GetResource<cMesh>(...) I get the linking error
If I try from App to construct cMesh I get linking the linking error
If I try from App to call static method that will return new instance of cMesh I get the linking error
If I comment out the construction of cMesh but leave other member cMesh function calls the App links fine. I can even call delete mesh.
I have never seen anything like it!
If you remove the cMesh constructor, then you are then using the default (no argument, no body) cMesh constructor that is given to you. It almost sounds like there's a build error or missing code as a result of some code in your cMesh constructor and so the library isn't actually getting generated, and perhaps Xcode isn't reporting the error. Xcode is no good at reporting linker errors.
I would suggest looking at what symbols the linker says are missing and double-check that they are actually defined in your code. My guess is that you're using one of those symbols in your cMesh constructor. A lot of times with virtual base classes, you may forget to define and implement a method or two in a child class. Could be a result of missing a method based on your template, or your template isn't #included correctly. This could compile fine but result in linker errors like you're seeing.
If Xcode isn't showing you the full linker error, show the Log Navigator (Command ⌘+7), double-click the last "Build " entry, select the error, and then press the button on the far-right of the row that appears when selected. The symbols should be listed there. If not, it's time for xcodebuild in the Terminal.
If it's not that case, I'd be interested in seeing the results of whether or not the library is being built for the appropriate architecture, or maybe this can spur some progress:
In the Xcode Organizer Shift ⇧+Command ⌘+2, click Projects and find the path to the DerivedData for your project.
In the Terminal, navigate to that directory (cd ~/Library/Developer/Xcode/DerivedData/proj-<random value>/)
Remove (or move aside) the Build directory (rm -r Build)
In Xcode, try to build with the cMesh constructor present.
Find the Library product file (cd Build/Products/<scheme>-iphoneos)
Your compiled static libraries (<libname>.a) should be in this directory. If they're not there, they didn't build (unless you put your products elsewhere). If your libraries are there, let's confirm that they actually are getting built for the appropriate architecture. Run otool -vh <library>.a. You should see something like:
$ otool -vh libtesting.a
Archive : libtesting.a
libtesting.a(testing.o):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC ARM V7 0x00 OBJECT 3 1928 SUBSECTIONS_VIA_SYMBOLS
As you can see, my test library was built for ARMv7.
Make sure you are linking them in the correct order.
If Component depends on symbols in Core, then Component needs to be first in the link order, so the linker knows which symbols to look for in Core.
In MSVC the order doesn't matter, but in most other compiler suites it does.
I don't think Clang generates code for armv6, if you're targeting devices that old you still need to use GCC.