There is some linker issue while compiling a cpp program
I use g++ and ubuntu 12.04
Installed uhd from repo.
libuhd.so file is located in /usr/lib
Now my question is
1.For linking uhd I used -luhd,but that gives me an error
undefined reference to `uhd::set_thread_priority_safe(float, bool)'
Should I add library path of libuhd to LD_LIBRARY_PATH?
I did that by the command
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/libuhd.so
After this I tried compiling again but same error?
It would be great if you could help me
Thanks
Is uhd::set_thread_priority_safe the only UHD function you are calling in your entire program? It is strange that that is the only undefined reference you are seeing from your program. If it is the only function in there, then it simply isn't finding the library. If it isn't, it sounds like the UHD version you have is strange.
Have you tried doing a:
$ sudo ldconfig
...after adding the library path to /etc/ld.so.conf?
When you say you installed it from the repo, what repo are you referring to? What distro are you running?
Related
I am really struggling to setup wxWidgets to work on Windows and CMake and would appreciate some help.
I have downloaded wxWidgets 3.1.4, run the setup (which extracted to C:\CPP_lib\wxWidgets) and then ran the following commands in the terminal:
cd C:\CPP_lib
mkdir wxWidgets-install
cmake C:\CPP_lib\wxWidgets -DCMAKE_INSTALL_PREFIX=C:\CPP_lib\wxWidgets-install -DwxBUILD_SHARED=OFF
cd wxWidgets-install
cmake --build . --target install
I have environment variables CMAKE_PREFIX_PATH set to C:\CPP_lib and wxWidgets_DIR and wxWidgets_ROOT_DIR both set to C:\CPP_lib\wxWidgets-install.
However, when I have a simple CMake project that calls find_package(wxWidgets), I get the following message in the terminal:
Found wxWidgets: winmm;comctl32;uuid;oleacc;uxtheme;rpcrt4;shlwapi;version;wsock32
missing components: core base png tiff jpeg zlib regex expat
Please help - I have been struggling for a while now :(
It turns out the issue was a very specific one related to vcpkg.
I had pointed CMake to my vcpkg toolchain file (even though wxWidgets was installed independent of vcpkg) and this was causing issues with finding wxWidgets i.e. vcpkg was preventing wxWidgets (a non-vcpkg installation) from being found.
I believe this is a vcpkg bug, although am not sure, but have reported it anyways.
Want to cross-compile a C application that uses Azure IoT SDK, which unfortunately requires Cmake. Cmake refuses to build my toolchain because it claims that it cannot find Openssl that I've compiled for my target architecture.
I've tried adding OPENSSL_ROOT_DIR to the folder it's in.
SET(OPENSSL_ROOT_DIR /path/to/openssl)
I continually get the error:
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES) (found
version "1.0.2g")
I also tried setting system variables to these folder as the error suggests, but it seemingly ignores them and prompts the same error. I've tried adding it to the same folder as my C compiler also to no avail.
I've run out of things to try and this point and I do not understand why it doesn't work. Any suggestions?
In Linux, I didn't have any problem setting OpenSSL.
In Windows, I solved as explained below.
Try removing CMakeCache.txt file and then do again. The cache Cmake is the main problem.
For instance, I did cmake . -DOPENSSL_ROOT_DIR=C:\openssl-1.0.2 -DOPENSSL_INCLUDE_DIR=C:\openssl-1.0.2\include -DOPENSSL_CRYPTO_LIBRARY=C:\openssl-1.0.2\crypto and everything got solved. The logic is same.
For MacOs I encounter the same error while installing ton'slite client (cmake ~/lite-client)
Solved as follows: I have open the "CMakeCache.txt" file in "liteclient-build" directory, find the line
OPENSSL_INCLUDE_DIR:PATH=OPENSSL_INCLUDE_DIR-NOTFOUND
and change it to with my openssl location
OPENSSL_INCLUDE_DIR:PATH=/usr/local/opt/openssl/include
I have downloaded ipopt and compiled it(I dont have libipopt.a, but I have libipopt.so and libipopt.la). When I try to compile scip with IPOPT=true, I get the error message:
fatal error: IpoptConfig.h: No such file or directory
I have already added the soft links. I don't know if it has anything to do with me not having libipopt.a?
After doing make install in Ipopt, you should have a directory include in the Ipopt build directory (or in the "prefix"-directory if you used --prefix) which should contain a file coin/IpoptConfig.h. Please check.
I had a similar issue. For me the problem was that in an older version of SCIP ipopt should be linked at scip/lib and in the newer version it is scip/lib/static.
I've tried official howto but failed. I got error:
"The procedure entry point InterlockedCompareExchange#12 could not be located in the dynamic link library libstdc++-6.dll"
The problem was due the old gcc compiler, bundled with DevKit from rubyinstaller.org (4.5 vs 4.8 on my PC). Use MSYS instead. Assume we have zeromq source inside D:\libs\zeromq, then the procedure is:
Download GUI MinGW installer.
Install base and MSYS (if you already have working gcc compiler you probably only need MSYS).
Launch MSYS environment by executing C:\MinGW\msys\1.0\msys.bat.
Follow Using MSYS with MinGW section:
mount c:/mingw /mingw
cd /d/libs/zeromq
./configure --prefix=/mingw
make
Copy /d/libs/zeromq/src/.libs/libzmq.dll to your desired place.
In fact I needed to use ZeroMQ with C++, so I downloaded zmq.hpp, moved it to include directory, and compiled hwserver.cpp to test it:
C:\MinGW\bin\g++.exe -o hwserver hwserver.cpp -L. -lzmq -ID:\libs\zeromq\include
It worked, but when I launch it I got:
Assertion failed!
Program: D:\tmp\zmq\hwserver.exe
File: D:\libs\zeromq\include/zmq.hpp, Line 280
Expression: rc == 0
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I've managed to get rid of this failure by commenting lines 279, 280. Similar issue
When i compile example2.cpp with armadillo makefile and run it i am getting an error message
error: det(): use of ATLAS or LAPACK needs to be enabled
How do i fix that? I have similar errors when i try to use solve. Details of my setup are:
Ubuntu Lucid Lynx 10.04
Armadillo version: 2.4.2 (Loco Lounge Lizard)
ATLAS 3.9.51
BOOST 1.48.0
g++ (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
Atlas was installed before armadillo was, armadillo installation was configured with Cmake. I am far from an expert in cmake, but i thought that it was supposed to find ATLAS when i generated makefiles with it. Armadillo documentation seem to say that if i install with cmake i don't need to do any manual enabling of ATLAS. I tried to manually hack example2.cpp by inserting
#define ARMA_USE_ATLAS
before the headers, but it just generates a bunch of errors regarding missing stuff on Cblas. Maybe there is a step missing to allow cmake to find ATLAS. It feels i am missing something simple but key. Any help would be greatly appreciated.
Additional Detail:
Edit: for whatever reason i cannot add comment anymore, so i am posting a reply to #Appleman1234 answer below here.
I compiled armadillo and ATLAS from source. I thought that ATLAS has LAPACK and BLAS bundled in and optimized. When i compiled it, i passed a location to lapack tar like
./configure --shared --with-netlib-lapack-tarfile=/<path>/lapack-3.3.1.tgz
I also see in atlas lib directory the following files:
libatlas.a, libcblas.a, libf77blas.a, liblapack.a, libptcblas.a, libptf77blas.a libsatlas.so, libtatlas.so
which seem to indicate that blas, cblas, and lapack are installed on the system. However, CMakeCache.txt in armadillo seem to indicate that cmake didn't find BLAS, CBLAS, CLAPACK as follows
BLAS_LIBRARY:FILEPATH=BLAS_LIBRARY-NOTFOUND
There is no notion of ATLAS in CMakeCache.txt, so i assume that it wasn't found either. Maybe i am mistaken, but it seems that i somehow need to point cmake to ATLAS, i just don't know how. I could also be at error assuming that ATLAS has BLAS, LAPACK and CBLAS. I thought i compiled them as a part of ATLAS, but i could be wrong. Would appreciate your comments.
Solution to the problem:
What Dirk suggested almost worked. The problem as i mentioned in one of the replies to his post was cmake was balking. I misdiagnosed that as a problem with cmake not finding clapack. In fact, after looking more carefully at cmake output i realised it had problems with not finding good compiler or rather dragging its feet when it decided to use as compiler /usr/bin/c++. So i did CXX=g++ and then cmake again which worked fine. After that armadillo compiled fine.
Did you install armadillo from source ?
What did cmake output when running cmake . or ./configure ?
The latter just calls cmake ..
Did it output the values below ?
-- CLAPACK_FOUND = YES
-- CBLAS_FOUND = YES
If they are not YES, then according to CMakeLists.txt, ARMA_USE_ATLAS is set to false and ATLAS isn't used.
In order to use det or solve, install CLAPACK and CBLAS if you want to use ATLAS or just install LAPACK.
As armadillo exists in Debian / Ubuntu, you could simply install all the known build-dependencies to ensure you have all the -dev packages you need:
edd#max:~$ sudo apt-get build-dep armadillo
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
edd#max:~$
Appears that my system in complete in that regard.