I have my own program with plugins (dynamic shared libraries) on a linux (ubuntu) system. My libraries (plugins) use OpenCV (maybe not so important).
My plugins are in /usr/local/lib/mysoft/.
I have compiled my program successfully even with libraries, successfully installed so everything seems to be OK up to this point.
When I run my program, it loads a bunch of these libraries based on some configuration file. I have several libraries which are loaded successfully but I cannot load one library. It gives me error when loading (used dlopen() to open the library):
/usr/local/lib/mysoft/libMyPlugin2.so: undefined symbol: _ZN2cv6resizeERKNS_11_InputArrayERKNS_12_OutputArrayENS_5Size_IiEEddi
Segmentation fault (core dumped)
Tue Nov 20 19:11:29 CET 2012
It obviously has some problems to find cv::resize which is part of OpenCV but I don't understand why.
I checked following things:
OpenCV is probably correctly installed since other libraries use it as well and are loaded without problems
no dependencies of my program, libMyPlugin2.so or OpenCV are missing (checked with ldd)
Architecture of all libraries and binaries seems to be the same (I checked it with objdump -f)
Does anybody have an idea what am I doing wrong?
This post seems to be so relevant but still didn't help:
Linux shared library that uses a shared library undefined symbol
Well I found the problem, hopefully it can help others...
The problem - I was missing one OpenCV library when compiling. So I replaced "opencv_core opencv_highgui" by "opencv_core opencv_imgproc opencv_highgui" and everything works.
So although I was able to compile it one of the dependencies was missing - I guess something has changed in OpenCV cause these sources worked perfectly (even with build) with older versions of the OpenCV.
Related
I have one windows project built in VS 2015 in windows7. Now I have to use one third party library (implemented in C) built in Mingw - 64 bit (for windows). When I try to link this library I am getting one compilation error :--
Unresolved external symbol __chkstk_ms.
Now I have resolved this issue by linking 2 more libs - libgcc.a and libssp.a.
But after, that when I run my application, I have started getting memory exception in some routines which was working fine previously.
I have doubt I should not solve this compilation error by using these 2 libraries (as these are not windows). Instead of it, there should be some windows / VC run time library which should be providing implementation of this routine.
Can someone please suggest right way to resolve this linking error.
I recently switched my PC at work from Ubuntu to Arch Linux.
And I am now getting the following error (I am using stack to build my project):
setup-Simple-Cabal-1.22.4.0-ghc-7.10.2: Missing dependency on a
foreign
library:
* Missing C library: HSrts-ghc7.10.2
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
As far as I understand it, the difference in Linux Distribution should not cause any issue.
Things I have tried:
-add the path where the library is with --extra-lib-dirs
-make sure that the version of stack/ghc are the same acrose both systems
-tried unsucesfully to find a relevant difference between the 2 systems
(gcc version was different but didn't change anything)
I have a docker container based on ubutu where it builds without an issue.
The only thing I can think of is that this library gets handled differently from some random C-library since it contains the Haskell-Runtime. But I have no idea what this difference would be. Or how a differnent handling would cause an issue on my Arch System.
Here my .cabal file (the folder also contains the whole project):
https://github.com/opencog/atomspace/blob/master/tests/haskell/libExecutionOutputTest/opencoglib.cabal
Okay i figured out a workaround, instead of specifiyc the library in the .cabal file:
...
extra-libraries: HSrts-ghc7.10.2
...
you add it to your stack.yaml file:
...
ghc-options:
package-name: -lHSrts-ghc7.10.2
...
If you also have a exectuable defined in your .cabal file this will break the executable, since the library is not only included in the library. And including the runtime library in an executable results in an instant segementation fault.
I have a problem with the libstdc++.so.6 library when I execute a program in MATLAB. The code works fine on my laptop and my desktop, which is why I'm sure the problem is a library or linking compatibility issue:
/home/arturo/Virality/viral_cluster_ml/Viral_features/code/segment_pedro/segment: error while loading shared libraries: libstdc++.so.6: wrong ELF class: ELFCLASS64
I've google some answers on how to fix the library, and some say that I should remove the library to later re-install the correct version:
error while loading shared libraries: libstdc++.so.6: wrong ELF class: ELFCLASS64
The problem is that I can't afford the luxury to delete a library, because I am ssh'ing to a cluster at the lab I'm working in. I really wouldn't want to mess up any programs that are running at the cluster, so isn't there another way of fixing this problem? I'm hoping a solution similar to:
sudo apt-get install libstd++6
that doesn't require me to delete or modify any files, but rather to install them.
Or maybe the error is that I'm not linking the library correctly?
The file does exist, as when I use
locate libstd++.so.6
the computer finds it at these directories:
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2012b/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2012b/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2012b/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6
/usr/local/MATLAB/R2012b/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6.0.13
/usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2013a_DCS/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2013a_DCS/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/bin/glnxa64/libstdc++.so.6
/usr/local/Matlab_R2012a/bin/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/sys/os/glnxa64/libstdc++.so.6
/usr/local/Matlab_R2012a/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.py
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyc
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyo
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.py
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyc
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo
I've also tried setting the path to the the file before running MATLAB, without anyluck:
LD_LIBRARY_PATH=/usr/lib64:/home/arturo/Virality/viral_cluster_ml/Viral_features/code/scene_sun ./matlab
Similar link and problem:
http://www.linuxquestions.org/questions/linux-newbie-8/apt-get-messed-up-812346/
Problem was solved by recompiling a subfolder of the code on the cluster.
Let me start out by saying that I'm not a C developer and I know very little about actually writing real world C code. I've been doing some research to find a xUnit framework that I can use to write tests for C code and based on what I've found it seems like Unity is the one that I want to go with. It seems simple enough, but I really just don't know what to do after I download the zip file from Unity's website. It doesn't seem to have the normal configure/make/make install, and if it did, I'm not sure that is what I should be using anyway. It does, however, ship with some rake tasks, but none of those seemed to be any kind of "install" task. As a last resort I tried to just copy the 3 source files in with my code (which I really hope is not the right thing to do), but when I try that I get an error trying to compile my c file with gcc, but I think this should be working. Here is my set up:
src/
mycode.c
unity.c
unity.h
unity_internals.h
Here is the source for mycode.c
/* mycode.c */
#include "unity.h"
void test_sample(void)
{
TEST_ASSERT_EQUAL_INT(0, 0);
}
When I run gcc mycode.c I get:
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
"_UnityAssertEqualNumber", referenced from:
_test_sample in ccyHByv6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
(I get a similar error when I try to compile unity.c with gcc). Which I assume means that the code that ships with unity requires a different compiler than what I have which is:
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
or that maybe unity is not compatible with a 64 bit processor... (I'm running on Mac OS 10.7.3 with a 2.4 GHz Intel Core 2 Duo processor - another thing that may or may not be relavent is that I've got XCode Version 4.3 (4E109) and also Command Line Tools for XCode) At this point I'm just grasping at straws and I'm in way over my head.
My question is, what is the correct process to go through to take a 3rd party C library, such as Unity, and make it available to my C code? Do I need to install something like in Python or Ruby or add something to my path like in Java or something else? Shouldn't just dropping unity's code in with mine work? Am I doing something wrong or is Unity or both? I really just want to be able to test drive C code using Unity. Any help would be greatly appreciated. Thanks in advance!
First, try 'gcc *.c -o mytest'. This will compile all of the C source files into object files, and then link them together into the binary 'mytest'. Keep in mind that all C source files have to be compiled to object files before they can be linked together. (A library is just a bunch of packaged object files.)
If you had a unity library installed in /usr/lib, you could do something like 'gcc mycode.c -lunity -o mytest'. If you had a unity library sitting in the current directory, you might do 'gcc mycode.c ./unity.a -o mytest'. This tells the compiler to look for a file named 'unity.a' in the current directory. Some libraries build .so files ('shared object' files, similar to DLLs in Windows). Replacing 'unity.a' with 'unity.so' should work if that is the case. (I'm assuming a Unix/Linux environment here.)
As an alternative to Unity, look at Google Test, which can be used with C code. I know it is supported on the Mac as well. The primary benefit is a large and active community. More information on Google Test from another SO question: Is Google Test OK for testing C code?
I figured out my problem. It turns out that unity requires you to define a setup and a teardown function and if you do not, you will get errors similar to the one that I was running into.
I have installed gmp library many times and run several programs. Every time I run my first program after 'successful' compilation, i hit the following error.
./a.out: error while loading shared libraries:
libgmp.so.10: cannot open shared object file: No such file or directory
After immense amount of looking over the net, I was not able to resolve this issue correctly.
PS: One suggestion in one of the forums was to create the link to the library file in i think /usr/lib. But it was condemned badly in the same thread.
Eventually I want my code to run. A quick solution for this issue would be appreciated.
Thanks!!
Try ldd ./a.out which should show you where the system is looking for the lib. But yeah, it means that it's not correctly installed, or that the search path for this lib is not good.
So the symlink may be a good idea. How did you installed GMP on your computer? apt-like or compilation?