I have looked at many other posts related to this issue and have tried each solution. None have worked in my case, including copying over the makevars from Rcpp. Anyhow, when building on Travis I get the following error
undefined symbol: dpotrf_’
The interesting note is that the package installs fine on windows, macOS, and linux.
here is my repo R package
I can reproduce the failure on a very standard Debian testing system (which I use for the extensive reverse dependency checks on Rcpp and RcppArmadillo).
After installing packages bain and BFpack (I had the rest) I attempted to build the tar.gz from your pristine just-checked-out sources. And I get:
*** installing help indices
*** copying figures
** building package indices
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘BGGM’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/tmp/Rinst106c6ed5251a/00LOCK-BGGM/00new/BGGM/libs/BGGM.so':
/tmp/Rinst106c6ed5251a/00LOCK-BGGM/00new/BGGM/libs/BGGM.so: undefined symbol: dpotrf_
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/tmp/Rinst106c6ed5251a/BGGM’
-----------------------------------
ERROR: package installation failed
This appears to be a moderately complex and large enough package so please pardon me for not diving in and debugging. I would suggest you simplify with smaller mock packages to see what may be wrong. (dpotrf is a fairly standard LAPACK routine so something somewhere calls it. Maybe you call it explicitly. Maybe you did a Fortran-to-C mapping wrong. Maybe you have something wrong in how you interface with RcppArmadillo. Hard to tell...)
Edit: You committed compiled code and a Windows library. "Don't do that." When Travis builds it also starts from a git checkout as I did. That may be the difference.
Edit 2: It wasn't, but your R code mixes .Call() with generated entry points (ie via RcppExports.cpp and RcppExports.R). I have seen that blow up for other people. That may be something to look into.
Disclaimer: I work with D_Williams, but I figured out the problem, and others may find it useful.
A functioning configure.ac was present, and a Makevars.in is present.
The problem is that the configure file was not yet generated. This is an autotools/autoconf setup. To resolve it, I ran autoconf in the package directory, which generated the configure file. That configure file is then executed when R builds the package. The configure file modifies the Makevars.in and creates Makevars. That Makevars file ultimately defines where to find libraries, includes, compilers, compiler options, etc.
If you do not generate the configure file from configure.ac using autoconf, then there is no configure file to be executed, and no Makevars to define the needed options at compile time. Therefore, the compiler is not fully configured, and it will fail.
TLDR: If you have an configure.ac, you must run autoconf on it, and commit that configure file to your repo. R needs to execute it to have a functioning Makevars.
Related
Problem summary
When running mypy on my code, I keep getting many Library stubs not installed errors.
Few examples below:
/opt/conda/envs/my_ci/lib/python3.9/site-packages/ray/core/generated/agent_manager_pb2.py:5: error: Library stubs not installed for "google.protobuf.internal.enum_type_wrapper" (or incompatible with Python 3.9)
/opt/conda/envs/my_ci/lib/python3.9/site-packages/torch/utils/tensorboard/summary.py:8: error: Library stubs not installed for "six.moves" (or incompatible with Python 3.9)
/opt/conda/envs/my_ci/lib/python3.9/site-packages/ray/rllib/algorithms/algorithm.py:28: error: Library stubs not installed for "pkg_resources" (or incompatible with Python 3.9)
Currently I have to use the command
mypy --install-types --non-interactive my_folder --config-file=mypy.ini.
And although it solves the issue, the problem now is that it takes at least 2 min for installing missing types. This is very long for our CI/CD pipeline.
Question
What are alternative ways of addressing missing library stubs? E.g., such that I could maybe 'split' mypy install types (or other solution that is more time-consuming and potentially can be put as part of docker image), from pure run mypy command (that takes less time and runs as part of gitlab ci/cd pipeline).
I tried running mypy --install-types command first, and then run mypy without success. Could it be that I am doing something wrong?
I will appreciate any help and ideas!
I know I should ask this one in ROS Forums but I couldn't due to some reasons (Sorry for that). So the thing is, I built standalone RTAB package from source in my Ubuntu 18.04 (Bionic) with ROS Melodic installed. I am trying to launch the node for rtab mapping by writing this in my sourced catkin workspace:
~/catkin_ws$ roslaunch rtabmap_ros-master/launch rtabmap.launch rtabmap_args:="--delete_db_on_start" rtabmapviz:=false rviz:=true
But when i do this it raises RLE Exception Error even though the path given to rtabmap.launch file is correct and file is at the location. Error is something like that:
RLException: [rtabmap.launch] is neither a launch file in package [rtabmap_ros-master] nor is [rtabmap_ros-master] a launch file name
I don't know why its giving this same error and i am stuck here. Please Help!!!
As the error suggests it can not find a launch file for that package. This is usually caused by one of two things. The first is you need to make sure you're sourcing the correct setup file; here it would be source ~/catkin_ws/setup.bash
The second thing is that you need to make sure you're actually installing the launch files so that they can be used when built. Here that would mean your CMakeLists.txt has something like this:
install(DIRECTORY launch/
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}/launch
PATTERN ".svn" EXCLUDE)
I've created a tiny project [0] to reproduce an error in a controlled environment. The facts, I'm using jenkins to build my project, a big one, I'd like to make some parallel builds. Let me make it graphically
[MyBasicPackage] -----> [MyPackageTester] ------> [MyBasicApp]
.
.
+-----> [...]
+-----> [...]
this is the organization I've made on [0], I have a class TMyUnit (MyBasicPackage) registered on spring container to be tested. I build it and generate its .dcu, .bpl, and so on.
The second stage I build my MyPackageTester that requires MyBasicPackage. Finally I build the app that requires MyPackageTester. So far so good.
When I try to build my MyBasicPackage on, say PC-00, get the artifacts and try to build the the MyPackageTester on PC-06 (same arch, same OS, same IDE, same spring4d version), and a nice error arise:
Unit TMyUnit was compiled with a different version of Spring.Container.Registration
so, I update my spring4d on both machines (PC-00 and PC-06) and build them. Run... and same error arise.
check the library path options (C:\Program Files (x86)\Embarcadero\Studio\14.0\Componentes\spring4d\Library\DelphiXE6\Win32\Debug), delete dcu files and build them once again on both machines, same error.
copy dcu files from PC-00 to PC-06 to avoid any kind of system configuration and the same error arise.
Probably I'm trying to do something that's not possible so far. I've googled a couple of days without luck.
Any ideas?
Please feel free to fork or pull request the example ;)
Regards
[0] https://github.com/graguirre/DelphiDepencyExample
In your case you need to build with the Spring.Core runtime package. Not only will that prevent this error but your code will actually work.
If you do not then all modules will hold their own version of the GlobalContainer instance you are using and nothing will work.
Maybe one solution is put all your libraries in a centralized repository and pull them to compile your projects. It should resolve the different version error.
A C extension module that compiles fine on Travis-CI without anaconda fails when installed with anaconda. It appears to install just fine, but when I try to import it, I get the following error:
ImportError: /home/travis/anaconda/lib/python2.7/site-packages/quaternion/numpy_quaternion.so: undefined symbol: __log_finite
The full error can be seen here. Obviously, this looks like a linker error, where it can't find glibc (which I believe is where __log_finite is found). But why should it fail to find glibc?
When I run nm on that .so file (through Travis), it shows that __log_finite is indeed undefined, but shouldn't it find it through the usual process?
I've tried installing quaternion through pip and I've tried installing it by directly downloading it and running python setup.py install. Both seem to work, in the sense that it looks like all the files are where they should be. But both fail on import because they can't find that symbol.
I've even tried installing the full version of anaconda (rather than just miniconda, which is recommended). Nothing seems to work. How can I make Travis find that symbol, and is this something I'll have to worry about ordinarily with my distribution?
It appears to be a problem with a -ffast-math flag in my quaternion package. One thing that flag does is make the code assume that the numbers are finite, so that instead of using the log function, it uses some log_finite function, which for some reason Travis doesn't have --- or something. Anyway, I have my numba package set an environment variable in Travis builds, which the quaternion package then looks for on installation, and turns off fast-math. This is unfortunate, because it means I'm not actually testing the code as it's actually used. But it means my code builds and tests pass.
There seems to be about one mention of this on the internet. Or not; I can't tell.
Is it possible to use Erlang with ZMQ on Windows? I have tried to use erlzmq2, but rebar fails to compile it with cryptic linker errors. Of course i can invest some time and investigate makefiles, but maybe other way exists?
Update
Whose who are interested in compilation errors can download latest erlang for windows and try to build erlzmq2 (Visual Studio 2012 compiler, msys sh and make). Error looks like:
cl : Command line error D8021 : invalid numeric argument '/Wl,-DLL,-IMPLIB:.libs
\zmq.dll.lib'
Makefile:541: recipe for target 'libzmq.la' failed
make[3]: *** [libzmq.la] Error 2
Please note that other erlang libs are compiling with this setup without any problems.
Your problem lies in compiling ZeroMQ for Windows. You haven't actually gotten to any Erlang yet. Here are some of the clues that tell you this:
Makefile:541: recipe for target 'libzmq.la' failed
This line says there's a problem on line 541 of the Makefile. But in erlzmq2, you can see that neither the main Makefile nor the c_src Makefile (which is what would build libzmq.la) has anything close to that many lines.
make3: * [libzmq.la] Error 2
The [3] means that you're 3 invocations deep into Make. Specifically, you started at the top-level Makefile, which called Rebar, which ran make -C c_src, which downloads ZeroMQ version 3.2.2 and tries to do a ./configure && make
To fix this Unix-style, go into the deps directory of erlzmq2 and figure out how to correctly compile ZeroMQ. Hopefully, you will just need to pass some arguments to configure. Then you can edit c_src/Makefile and set ZMQ_FLAGS to whatever you had to do for configure, clean, and make.
To fix it more Windows-style, follow the Windows build instructions for ZeroMQ. Put the compiled libzmq under deps and just edit the c_src Makefile to a no-op.
Finally, if you don't actually need to run this code on Windows, but are just using Windows as your development environment, I think you'll have the easiest time by running the build inside a Linux VM (not a hard thing at all with tools like Vagrant). Sorry, but Unix is the real system for this stuff; Windows support is an afterthought.