I am using the armadillo library inside a package (LAMMPS package). I also used Armadillo to compile different codes, and it works fines, and I use the following compiling command:
g++ example2.cpp -o example2 -O3 -larmadillo -DARMA_DONT_USE_WRAPPER -lblas -llapack
Armadillo works fine for matrix storage and loading inside the package, however, when it comes to matrix-vector multiplication, it gives me the following error:
/usr/include/armadillo_bits/wrapper_blas.hpp:42: undefined reference to `dgemv_'
Any suggestion on how to go around it?
Related
Disclamer: using -nostdcincl isn't possible because it excludes needed system libraries. Here instead the problem seems to be that tthe compiler ignores my -I directives
I have installed a library (OpenCV) in ~/local on a remote machine, since I don't have sudo access there. Notice that an older version of the same library is installed in /usr/local.
I'm trying to compile this code:
g++ -DCC_DISABLE_CUDA -I/home/spm1428/CloudCache -I/home/spm1428/local/include/opencv -I/home/spm1428/local/include/opencv2 -I/usr/include/boost -I/home/spm1428/vlfeat -O3 -g -Wall -c -fopenmp -std=c++11 -c -o Descriptor.o ../Descriptors/Descriptor.cpp
However, the returned error is:
In file included from /usr/local/include/opencv2/opencv.hpp:77:0,
from /home/spm1428/CloudCache/Utilities/Utility.hpp:11,
from ../Descriptors/Descriptor.cpp:17:
/usr/local/include/opencv2/highgui/highgui.hpp:165:25: error: redeclaration of ‘IMREAD_UNCHANGED’
IMREAD_UNCHANGED =-1,
^
In file included from ../Descriptors/Descriptor.cpp:13:0:
/home/spm1428/local/include/opencv2/imgcodecs.hpp:65:8: note: previous declaration ‘cv::ImreadModes IMREAD_UNCHANGED’
IMREAD_UNCHANGED = -1, //!< If set, return the loaded image as is (with alpha channel,
^
In file included from /usr/local/include/opencv2/opencv.hpp:77:0,
from /home/spm1428/CloudCache/Utilities/Utility.hpp:11,
from ../Descriptors/Descriptor.cpp:17:
/usr/local/include/opencv2/highgui/highgui.hpp:167:24: error: redeclaration of ‘IMREAD_GRAYSCALE’
IMREAD_GRAYSCALE =0,
I think that this happens because there is another version installed. How can I solve this?
I think this error happens for the same reason (the old version doesn't have cv::xfeatures2d::SURF).
I have been using clang-3.5 to happily build bitcode versions of musl libc and
use the result to produce nice stand alone executables.
Recent attempts with clang-3.8 have not been so happy. It seems that
the bitcode clang-3.8 generates uses functions defined in
compiler-rt/lib/builtins
Typical examples of functions I find polluting the bitcode are mulxc3, mulsc3, and muldc3. I can solve this by linking against libgcc, or even the llvm alternative if I had any clear idea of what that was. Though I would rather prevent the problem from happening in the first place.
I have seen mention of flags like rtlib=compiler-rt etc, but have found precious little documentation on the subject.
So here are some simple questions.
Is it possible to prevent clang from using the compiler-rt/lib/builtins
in the emitted bitcode? Or if not
Does llvm produce a version of libgcc that I could use. Actually I would
probably build a bitcode version of it, but that is besides the point.
Love to hear some guidance on this.
Added 12/8/2016: So I will illustrate my issues with a particular workflow that
people can reproduce if they wish, or, more likely, just point out where I am being stupid.
So start by checking out:
musllv
and follow the instructions in the README.to compile (here I am using clang-3.8 on ubuntu 14.04)
WLLVM_CONFIGURE_ONLY=1 CC=wllvm ./configure --target=LLVM --build=LLVM
make
cd lib
extract-bc -b libc.a
you will also need the bitcode of a simple executable. I will use nweb.c here.
wllvm nweb.c -o nweb
extract-bc nweb
Now we can do things like:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
This workflow goes smoothly for clang-3.5 but for clang-3.8 we get:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
/tmp/libc-f734a3.o: In function `cpowl':
libc.a.bc:(.text+0xbb9a): undefined reference to `__mulxc3'
/tmp/libc-f734a3.o: In function `cpowf':
libc.a.bc:(.text+0x38f7d): undefined reference to `__mulsc3'
/tmp/libc-f734a3.o: In function `csqrt':
libc.a.bc:(.text+0x78fc3): undefined reference to `__muldc3'
/tmp/libc-f734a3.o: In function `cpow':
libc.a.bc:(.text+0xafafc): undefined reference to `__muldc3'
clang-3.8: error: linker command failed with exit code 1 (use -v to seeinvocation)
So as #paul-brannan points out we could try
clang -static -nostdlib --rtlib=compiler-rt nweb.bc libc.a.bc crt1.o libc.a -o nweb
But this is where I am probably being stupid, because I get:
clang-3.8: warning: argument unused during compilation: '--rtlib=compiler-rt'
irregardless of whether I use it as a linking or compiling flag.
OK so I finally managed to make headway on this. I built llvm-3.8.1 together with the compiler-rt project using wllvm and wllvm++.
One of the build products was libclang_rt.builtins-x86_64.a,
and from this archive I was able to extract the bitcode module
libclang_rt.builtins-x86_64.bc
using the command:
extract-bc -b libclang_rt.builtins-x86_64.a
This bitcode module has definitions for those pesky instrinsics like
__mulxc3, __mulsc3, and __muldc3.
Hallelujah!
I am at a loss to solve a particular issue I have: I cannot pinpoint the culprit.
System: Jetson TX1, arm64 kernel, 32b userspace, opencv4tegra
Situation: Have been building projects using:
find_package( OpenCV )
And this has worked fine and compiled.
Fault: I built from source and installed CMake 3.5.2. Now I can no-longer build any projects that depend on OpenCV. I get linker errors that point cannot find:
opencv_dep_cudart
I am assuming the issues are caused in OpenCVCConfig.cmake, around this point:
# Import target "opencv_core" for configuration "Release"
set_property(TARGET opencv_core APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(opencv_core PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "opencv_dep_cudart;opencv_dep_nppc;opencv_dep_nppi;opencv_dep_npps;dl;m;pthread;rt;tbb"
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libopencv_core.so.2.4.12"
IMPORTED_SONAME_RELEASE "libopencv_core.so.2.4"
)
Out of the file: /usr/share/OpenCV/OpenCVModules-release.cmake
However, this file doesn't change between CMake versions as it is an OpenCV file. So this must be how it is processed.
Reverting my CMake back to 2.8.12.2 manually allowed me to build again. Here is an example of a make command that uses OpenCV. Note the correct cuda libs:
Linking CXX executable DuoInterfaceTest
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/DuoInterfaceTest.dir/link.txt --verbose=1
/usr/bin/c++ -O2 -g -DNDEBUG -std=gnu++11 CMakeFiles/DuoInterfaceTest.dir/src/mainTest.cpp.o -o DuoInterfaceTest -L/home/ubuntu/catkin_ws/duointerface/lib/linux/arm -rdynamic libDuoInterface.a /usr/lib/libopencv_vstab.so.2.4.12 /usr/lib/libopencv_tegra.so.2.4.12 /usr/lib/libopencv_imuvstab.so.2.4.12 /usr/lib/libopencv_facedetect.so.2.4.12 /usr/lib/libopencv_esm_panorama.so.2.4.12 /usr/lib/libopencv_detection_based_tracker.so.2.4.12 /usr/lib/libopencv_videostab.so.2.4.12 /usr/lib/libopencv_video.so.2.4.12 /usr/lib/libopencv_ts.a /usr/lib/libopencv_superres.so.2.4.12 /usr/lib/libopencv_stitching.so.2.4.12 /usr/lib/libopencv_photo.so.2.4.12 /usr/lib/libopencv_objdetect.so.2.4.12 /usr/lib/libopencv_ml.so.2.4.12 /usr/lib/libopencv_legacy.so.2.4.12 /usr/lib/libopencv_imgproc.so.2.4.12 /usr/lib/libopencv_highgui.so.2.4.12 /usr/lib/libopencv_gpu.so.2.4.12 /usr/lib/libopencv_flann.so.2.4.12 /usr/lib/libopencv_features2d.so.2.4.12 /usr/lib/libopencv_core.so.2.4.12 /usr/lib/libopencv_contrib.so.2.4.12 /usr/lib/libopencv_calib3d.so.2.4.12 /usr/lib/libopencv_tegra.so.2.4.12 /usr/lib/libopencv_stitching.so.2.4.12 /usr/lib/libopencv_gpu.so.2.4.12 /usr/lib/libopencv_photo.so.2.4.12 /usr/lib/libopencv_legacy.so.2.4.12 /usr/local/cuda-7.0/lib/libcufft.so /usr/lib/libopencv_video.so.2.4.12 /usr/lib/libopencv_objdetect.so.2.4.12 /usr/lib/libopencv_ml.so.2.4.12 /usr/lib/libopencv_calib3d.so.2.4.12 /usr/lib/libopencv_features2d.so.2.4.12 /usr/lib/libopencv_highgui.so.2.4.12 /usr/lib/libopencv_imgproc.so.2.4.12 /usr/lib/libopencv_flann.so.2.4.12 /usr/lib/libopencv_core.so.2.4.12 /usr/local/cuda-7.0/lib/libcudart.so /usr/local/cuda-7.0/lib/libnppc.so /usr/local/cuda-7.0/lib/libnppi.so /usr/local/cuda-7.0/lib/libnpps.so -ldl -lm -lpthread -lrt -ltbb -lDUO -Wl,-rpath,/home/ubuntu/catkin_ws/duointerface/lib/linux/arm:/usr/local/cuda-7.0/lib
Thoughts? I would like to be able to keep the newer CMake on my system but don't understand enough to fix the problem. If you think this is too system-unique I will withdraw the question.
As noted by Michael Mairegger, you have to cmake in the build directory by doing
sudo cmake .. -DCUDA_USE_STATIC_CUDA_RUNTIME=false
But one extra thing I noticed is that if I try to make afterwards it won't work unless I do the cmake command twice.
I'm trying use rebar to generate a 32-bit arch release on 64-bit arch system. It's unclear to me how I need to modify an application's rebar.config to be able to do this.
I have taken a look at the rebar source to see how they are detecting my environment: rebar_utils.erl gets the architecture as "x86_64-unknown-linux-gnu" and this is set in rebar_port_compiler as the "default_env". I'm wondering how I can get rebar to compile for another target architecture.
I have tried the following port_env options
{port_env, [{"CFLAGS", "$CFLAGS -fPIC -m32"},{"LDFLAGS", "-arch i386"}]}.
With those options (and a 32-bit Erlang installation in my path), when I run rebar get-deps compile my dependencies are still being built as 64-bit and thus ld skips over my 32-bit libraries (and ultimately fails because it cant find a 64-bit implementation)
/usr/bin/ld: skipping incompatible <PATH TO 32-bit erlang install>/lib/erlang/lib/erl_interface-3.7.14/lib/liberl_interface.a when searching for -lerl_interface
/usr/bin/ld: cannot find -lerl_interface
collect2: ld returned 1 exit status
ERROR: sh(cc c_src/epam.o $LDFLAGS -shared -L"<PATH TO 32-bit erlang install>/lib/erlang/lib/erl_interface-3.7.14/lib" -lerl_interface -lei -o priv/lib/epam.so)
What do I need to do to force my dependencies to compile as 32 bit? My attempt here isn't working.
The port_env settings in rebar.config can make use of the ERLANG_ARCH environment variable to determine whether the Erlang runtime was built for a 32- or 64-bit system. For example, the following port_env definition sets either -m32 or -m64 as appropriate for the C compiler for the x86_64, i686, and i386 chip architectures:
{port_env, [{"x86_64", "CFLAGS", "$CFLAGS -m$ERLANG_ARCH"},
{"i[36]86", "CFLAGS", "$CFLAGS -m$ERLANG_ARCH"}]}.
The first string in each tuple is a regular expression matched against the system architecture string of the Erlang runtime as returned by the erlang:system_info(system_architecture) function. In this example, the additional -m$ERLANG_ARCH option is added only when the regular expression matches, and all other architectures get the default CFLAGS setting.
I want to use Mecab in Lua,but I really can't figure out the procedure of bindings,i am work no windows 7,is bingdings meaning that to create a shared library? if so? how to?i see some binding files about Java,the files in package org.chasen.mecab shows that it create by swig,it make me confused.so where does it derive from ? or just write by ourself?after bindings,what else should i do if i want to use in Lua,by the way I use mingw.can someone give some simple steps to me that I can keep trying to work on it.
to greatwolf:
i use followings command to do it
swig -lua -c++ MeCab.i
g++ -c MeCab_wrap.cxx -I C:\Lua\5.1\include -I ..\src
g++ -LC:\Lua\5.1\lib -shared MeCab_wrap.o -llua51 -o MeCab.dll
and i got errors below.
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2960): undefined reference to `_imp___ZN5MeCab12createTaggerEPKc'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2981): undefined reference to `_imp___ZN5MeCab12getLastErrorEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x29c9): undefined reference to `_imp___ZN5MeCab12createTaggerEPKc'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x29d9): undefined reference to `_imp___ZN5MeCab12getLastErrorEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2a8d): undefined reference to `_imp___ZN5MeCab11createModelEPKc'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2aae): undefined reference to `_imp___ZN5MeCab12getLastErrorEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2af6): undefined reference to `_imp___ZN5MeCab11createModelEPKc'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2b06): undefined reference to `_imp___ZN5MeCab12getLastErrorEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x2b6d): undefined reference to `_imp___ZN5MeCab13createLatticeEv'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x11050): undefined reference to `MeCab::Model::version()'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x11457): undefined reference to `MeCab::Model::create(int, char**)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x11732): undefined reference to `MeCab::Model::create(char const*)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x122bf): undefined reference to `MeCab::Tagger::parse(MeCab::Model const&, MeCab::Lattice*)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x17737): undefined reference to `MeCab::Tagger::create(int, char**)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x17a12): undefined reference to `MeCab::Tagger::create(char const*)'
MeCab_wrap.o:MeCab_wrap.cxx:(.text+0x17d83): undefined reference to `MeCab::Tagger::version()'
collect2: ld returned 1 exit status
it seems that these function declared in mecab.h，but i don't know how to handle it.
It looks like mecab provides a swig file for automatically generated bindings. As luck would have it, lua is one of swig's supported targets.
A reasonable starting point would be to check out the corresponding makefile to see how bindings get created for other languages. From mecab's swig makefile:
SWIG = swig
PREFIX = MeCab
all: perl ruby python java csharp
# ...
perl:
$(SWIG) -perl -shadow -c++ $(PREFIX).i
mv -f $(PREFIX)_wrap.cxx ../perl
mv -f $(PREFIX).pm ../perl
ruby:
$(SWIG) -ruby -c++ $(PREFIX).i
mv -f $(PREFIX)_wrap.cxx ../ruby/$(PREFIX)_wrap.cpp
python:
$(SWIG) -python -shadow -c++ $(PREFIX).i
mv -f $(PREFIX)_wrap.cxx ../python
mv -f $(PREFIX).py ../python
# ...
Extrapolating from the above, you can try generating swig bindings something like the following:
swig -lua -shadow -c++ MeCab.i
This will substantially reduce the effort you would otherwise need from manually creating the bindings yourself.
I don't know of any Lua bindings for mecab. Try googling for them first.
To create the bindings yourself you must be proficient both with Lua C API and C (or C++). A deep understanding of Lua itself (the language, I mean) is advisable.
Search the Lua WIKI for some more pointers. In particular BindingCodeToLua page.
I recently needed this and since I didn't find anything I wrote a module so you can use Mecab with Lua.
It works like this:
mecab = require "mecab"
parser = mecab:new("") -- you can pass mecab config options here, like "-Owakati"
print(parser:parse("吾輩は猫である"))
You can also install it via LuaRocks as mecab.
It just provides access to the parse method of the Tagger class, but when working with Mecab that's all I've ever needed. If you'd like support for other Mecab features please feel free to file an issue on Github.