I have build a program in linux(ubuntu 12.04) using arm-linux-gnueabi-g++.
The program compiles fine. When I transferred the program to an arm machine and tried to run I got this error:
error while loading shared libraries: libPVROCL.so: cannot open shared object file: No such file or directory.
I copied the library to the /usr/local/lib folder of the arm machine but it did not work. I cannot change the conf file or environvent variables of the arm machine. The arm system is stripped down to the extent that it doesn't have ldconfig or ldd or much else. ldd run on another more capable system against the executable shows this line:
not a dynamic executable
Can anyone give me a solution or show me a path? Any help will e appreciated.
I tried to build the code statically and I specified all the libraries with their full path. But I could not build as it gives me another error:
attempted static link of dynamic object `/OpenCV/opencv/install/lib/libopencv_core.so'
Related
I have a compiled script (it's some utility) and the source code of which is unavailable. As soon as I run the script this error shows up:
error while loading shared libraries: librun.so: cannot open shared object file: No such file or directory
I have faced these kind of errors in past which had different solutions. I tried all as per my knowledge and..
librun.so is there in lib folder of my application
It is symbolic link and pointing to correct version
librun.so is available in path variable
changed .profile to look for the required library
changed permissions and checked
"which librun.so" is also returning the presence of that library
still this error shows up.
What can be the reason for this problem?
The dynamic linker is unable to find librun.so during runtime linking of shared libraries. Try adding the path of directory containing librun.so to the LD_LIBRARY_PATH environment variable when starting the application script.
On a Linux system, I am trying to run a Fortran program that makes use of some shared libraries (netCDF libs, if that makes a difference). Before I run, I set LD_LIBRARY_PATH so that it points to the location of my libraries. Then I run the executable and I quickly get the error
../my_program: error while loading shared libraries: libnetcdff.so.5: cannot open shared object file: No such file or directory
Now, I double check the value of LD_LIBRARY_PATH, and then cd to it and find plain as day
$ ls *ff*
$ libnetcdff.a libnetcdff.la libnetcdff.so libnetcdff.so.0 libnetcdff.so.0.0.0
So the libnetcdff is absolutely present.
Could anyone point me to the problem?
The one thing that has occurred to me is that the executable seems to want to find libnetcdff.so.5, while the library that is present is actually libnetcdff.so.0. Is that the problem? If so, is there a way to convince the executable to not insist on "5"? Alternatively, would a link from libnetcdff.so.0 to libnetcdff.so.5 solve the problem? (I don't have permissions in the directory, BTW, which is why I haven't tried that yet.)
Environment info: CentOS machine, code compiled with gfortran. And yes, when I compiled, my -L flags were pointing to the same directory that LD_LIBRARY_PATH points to.
Thanks.
A library link should work. Since you mention that you do not have root/sudo access, what you can do is link in a file you do have access in:
ln -s /path/to/libnetcdff.so.0 /path/you/have/access/to/libnetcdff.so.5
And then add in the /path/you/have/access/to/ in your LD_LIBRARY_PATH.
I previously had some troubles updating old code that still needed a not supported compiler and expensive libraries to a version with gfortran in Eclipse on Windows. I let it rest for a while and recently I took a whole other approach, rebuilding the program from scratch, developping on a ubuntu machine, but now I want to bring it back to a windows machine so that my co-workers can contribute on it.
The status:
Program compiles, runs and gives good results on an ubuntu machine with the GCC GNU compiler
Windows 7 machine, 64bit
Cygwin installation (for gnu fortran) with lapack and liblapack-devel (however, I don't use these, because I compile blas and lapack manually)
(C:/cygwin/lib added to windows Path)
Original Issue:
The program compiles in cygwin (by calling the make-command, calling the make command with the makefile situated here: http://thijsvandenbrande.be/phd/hamfemInstall/makefile
This returns the file hamfem.exe which returns the following error when runned by double-clicking on it in windows: The program can't start because cyglapack-0.dll is missing from your computer. Try reinstalling the program to fix this problem.
When running the executable from cygwin, by calling the ./hamfem.exe command the executable starts to run. However, I want a solution so that I can give this executable to my co-workers so that they can change the input files (located in a folder in that has a relative path to the executable).
Going further on the comments below, I tried the next things:
Adding the exact path to the C:\cygwin\lib\lapack\cyglapack-0.dll file in windows path and even rebooting afterwards doesn't help.
adding a -static to the makefile before calling the library, resulting in dependency errors because I use two commands of the lapack library that depend on quite a lot of other commands (DPBTRF and DPBTRS). These commands are used in the mainprog.f90 module. The error: /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../liblapack.a(dpbtrf.f.o): In function 'dpbtrf':
/usr/src/debug/lapack-3.4.2-1/SRC/dpbtrf.f:277: undefined reference to 'dtrsm_'
and a couple of more lines stating the dependencies.
add the liblapack.a file to the src folder, but compiler always goes back to the lapack in cygwin
On the website of lapack you can normally download the functions with their dependencies (example DPBTRF), but these are not available anymore. Does anyone have another idea how to include these two functions and their dependencies in a static library-file that I can compile beforehand and add to the src-folder?
Current (semi-)Fix
The next thing worked (a bit) for me: following the instructions on http://gcc.gnu.org/wiki/GfortranBuild to manually build libblas.a and liblapack.a in the /usr/src folder of Cygwin and refering to this folder in the makefile. The updated makefile can be found here: http://thijsvandenbrande.be/phd/hamfemInstall/makefileNew
The code compiles nicely on Windows by running the make command from cygwin (next step in the process, running it out of Eclipse) and i get a .exe file that can be run by double clicking it and that keeps running if I move it with its folder to another location. Because this process is quite labour intensive, figuring it all out, I added the answer here below, stating the commands you have to parse to cygwin in order to make it work.
For your information: my file structure looks like this (after the build, I move the .exe file one folder up, both in the linux version as the windows version):
hamfem.exe
in
input.txt
NGCR_building01.txt
out
(empty folder for output files of the routine)
src
hamfem.f90 (main file)
mainprog.f90 (file that contains the commands from lapack)
...(a bunch of other modules)
makefile
I figured things out myself, with some pointers from all over stackoverflow. In order for others to help them resolve similar issues, I would like my work method here so that the question is fully documented.
The issue can be resolved by clean building the Lapack library !and the Blas library on your local machine in cygwin and pasting the liblapack.a and libblas.a file to the library folder that you refer to in the makefile. The errors that were casted by calling Lapack staticly where a result of some routines of Blas used in the two commands.
These are the steps I followed:
download the lapack.tgz and blas.tgz files from the website and past them in the C:\Cygwin\usr\src folder
Extract these files with the following commands in cygwin:
cd /usr/src
tar -xvzf lapack.tgz
tar -xvzf blas.tgz
Build the two library files with the commands shown below in Cygwin. Compiling Lapack can take a while and will result in some errors in the end because of some missing links in the test files. These tests are run for accuracy tools. A more detailed look into the make.inc file is needed to resolve these issues.
cd $HOME
cd /usr/src/BLAS
make
mv blas_LINUX.a ../libblas.a
cd ../lapack-3.4.2
mv make.inc.example make.inc
make
mv liblapack.a ../liblapack.a
check the makefile included in this repository for the correct linking to the libraries. These should say /usr/src and -static -llapack -lblas, the other options are for the linux compiler.
I have a problem in using GCOV_PREFIX environment variable.
Compiler version that I am using on build machine - gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
I am compiling my source files (*.c) using "fprofile-arcs –ftest-coverage" on build machine which produces an executable, object files (corresponding to each source file) and gcno file (corresponding to each source file) in the following location
/a/b/c/d
/a/b is mounted onto a test machine in the following directory "/tmp/test/a/b". On test machine, when I execute the executable, the same directory structure "a/b/c/d" is expected for creating *.gcda files.
Since it is not available, I get an error of this kind "profiling:/a/b/c/d/xyz.gcda:Cannot open".
But I do not want to create the same directory structure in my test machine.
I want to create a directory (/tmp/gcovfiles) in my test machine and I want gcda files to be created in /tmp/gcovfiles location.
I tried using environment variables GCOV_PREFIX and GCOV_PREFIX_STRIP. But it did not have any effect. May be I am not using it properly.
Could you please help?
I am trying to port my Qt code from Linux to embedded linux. Now I looked online and I came across this document on how to deploy onto embedded linux/linux:
http://doc.qt.io/archives/qt-4.7/deployment-x11.html
So now I use the shared-library approach since I think that will give me the most flexibility and also it seems that with the latest QtSDK I cannot deploy my application statically. I follow all the steps mentioned in the instructions and I have no plugins. So when I finish the steps I port all my code and the dependent libraries to a certain directory: /tmp/MyFolder.... I determine the libraries I need to port using ldd -v Application.exe. So now the thing is when I port the libraries onto embedded linux box I notice that some of those libraries already exist in directories such as /usr/lib and /lib. So when I run my code I write a shell script to modify the LD_LIBRARY_PATH environment variable to check those directories and my own directory for the appropriate libraries. Now when I run my code on the embedded linux box I get the error:
Error while loading shared libraries: /tmp/ftproot/RenderingEngine/./libm.so.6: ELF file OS ABI invalid.
I have tried googling the error but I still don't know what this error means and how to resolve it. The thing is the library libm.so.6 is in the /usr/lib directory and my custom directory as well. However, the way I set my LD_LIBRARY_PATH it checks my custom directory first. Could someone help me with this please?
The ELF error indicates that you have linked to libraries that are in an incompatible binary format for your system. You should only link to libraries that were compiled for the target OS (in this case whatever version of embedded Linux).
Try recompiling your code and link to the libraries that were already present on your system (i.e. in /usr/lib).