I am on a 64bits linux running an application which is compiled for 32bits and have some libs in its directory.
So I do:
export LD_PRELOAD_PATH=./
./my_app
Still, I get errors of not finding the lib.
Is there other variable name for 32 bits libs search path?
Ps: I am sure I am not the first one to ask that, but I couldnt fint it.
I believe you want LD_LIBRARY_PATH, preload is a different beast.
Related
I have instaled Cygwin after running MinGW for a while now. But when I try to compile the console gives me:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
What does this mean?
I have the same problem and I found the solution.
According to the FAQ of Cygwin
Q: Why is C:\cygwin\usr\bin invisible from windows?
A: Because it does not really exist. In cygwin, /usr/bin is just a link to /bin.
So trying to add "C:\cygwin\usr\bin" to PATH will be in vain.
Add "C:\cygwin64\bin" to PATH instead. Hope this helps :)
You are missing a library, please run cygcheck /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe or ldd /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe to see what is the missing library.
(I'd rather ask a question in the comments first, but I don't have enough reputation yet.)
Your cc1 is unable to load some DLLs it needs to start. Looking at the Cygwin source code, this can be either a library specified in LD_PRELOAD, or -- more probably -- a library the executable depends on. The ? in the error message seems to be the default return value of find_first_notloaded_dll (hookapi.cc), in case the function can't determine what library is missing.
To diagnose the issue, I suggest checking your PATH variable (or even clearing it of any non-Cygwin paths and trying the compilation again) and/or using Dependency Walker to find the missing DLLs (start it from a Cygwin shell, so it can see the same PATH). ldd (included with Cygwin) may also give some clues, but I wouldn't bet on it.
It's possible a clean re-install of Cygwin will be necessary to solve the issue.
Most likely, you are simply missing /usr/bin in the PATH variable.
Adding 'export PATH=/usr/bin:$PATH' to your .bashrc file will solve the issue.
Adding some background info. I had the same problem when building my own program and linking it against graphviz cgraph.dll. Turns out this is related to where windows searches for DLLs (see here: https://msdn.microsoft.com/en-us/library/7d83bc18.aspx) So adding the path of your missing library to PATH should fix the problem.
It is unfortunate that the message doesn't include the name of the library. Luckily cmd.exe DOES give you this name (so it's good for something after all;)
Are you including the path to your lib directory?
Looks like you are not
I'm not very familiar with Cygwin, I mainly use MinGW, but I think the error message speaks for itself
I also came this error on windows machine while executing .exe file generated by scilab2C i.e toolbox for Scilab
For Windows 32 bit Add the environment variable path as follow :
C:\cygwin\usr\i686-pc-cygwin\bin
Hope so this will solve your issue.
Just had this problem trying to compile a package with make and it wanted some cygguile dll file that was just installed along with make.
My solution was I had not only migrated my cygwin64 directory across drives because the sector sizes were mismatched for some reason even though the drivers were both under 2TB and should have been using 512 byte sector sizes.. So I had to install a new system and move files over there, might have had weird permissions on them.
Also had to patch cygwin1.dll end of Jan 2020 because of a recent input problem in ConEmu with Windows 10 1903 build, but just did it again with this working so that doesn't seem to be the issue.
Reinstalling cygwin by deleting that entire directory, taking ownership of it first.., seemed to work now...
(Note: names of the binary and binary and library below are obfuscated to protect the innocent. ;-) The app is proprietary under NDA but the behavior may not depend on it.)
I have a Linux binary which prints the following error when run:
binary: error while loading shared libraries: libshared.so: cannot open shared object file: No such file or directory
Which is confusing on its own since libshared.so is in the LD_LIBRARY_PATH. However,
The library is found correctly when running ldd binary (i.e., the ldd output points to the file location)
The library is found correctly when running strace binary, so that the program manages to print its usage information!
I have never seen an application which behaves differently when run on its own vs in strace, but I figure maybe someone else has seen this happen before? Any ideas how to resolve this?
I don't have the source so I can't rebuild. Running the app in production under strace is probably a non-starter. The OS is RHEL 6.2.
(Old question, but hopefully this will help somebody else)
Under new Linux installations, LD_LIBRARY_PATH is not used by the standard system runtime linker for programs with SUID set. It appears that strace, gdb and friends work differently, and do use LD_LIBRARY_PATH.
For suid programs, all libraries must be found in the system library cache. Check (as root) whether your "missing" library is present using
ldconfig -p | grep <my_library_name>
and, if anything's missing, add it to a new file in /etc/ld.so.conf or ld.so.conf.d/ as appropriate, and then rebuild using
ldconfig -v
Or remove the SUID bit if it's not required, of course.
This really helped me a lot!
I was having a similar problem where libraries were not being picked up properly from the LD_LIBRARY_PATH, even when the ldd command showed all libraries were satisfied. However, when troubleshooting using strace, it was working. In my case, however, the problem was that SGID (set group ID sticky bit being on). When the files were installed, the sysadmin did a recursive chmod that set it on all files (including the executables). Once the SGID was removed on the executables, the libraries were now found without strace and everything worked as it should using the LD_LIBRARY_PATH.
I have been trying to get opencv to work in eclipse and I've been following this tutorial to try and get it to work in eclipse. I've gotten to the part where I create my .so libraries which is running make -j8. This works fine when I run it on a 32 bit linux system. I get all the necessary files I need but I get an exception in Eclipse when I try to run my program.
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/joris/opencv/build/lib/libopencv_java246.so: /home/user/opencv/build/lib/libopencv_java246.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
After looking up what this means, I discovered that the library is 32 bit but my jvm is 64 bit. I can't change the jvm that I'm using, so I need to build my native libraries in 64 bit.
I tried building the opencv libraries on a 64 bit system now, but I am unable to find the libopencv_java246.so file that I got from building it on a 32 bit system.
user#BEL-8WF4XW1:~$ find /home/user/opencv/ -name *.so
/home/user/opencv/3rdparty/lib/mips/libnative_camera_r4.0.3.so
/home/user/opencv/3rdparty/lib/mips/libnative_camera_r4.2.0.so
/home/user/opencv/3rdparty/lib/mips/libnative_camera_r4.1.1.so
/home/user/opencv/3rdparty/lib/armeabi-v7a/libnative_camera_r2.3.3.so
/home/user/opencv/3rdparty/lib/armeabi-v7a/libnative_camera_r4.0.3.so
/home/user/opencv/3rdparty/lib/armeabi-v7a/libnative_camera_r3.0.1.so
/home/user/opencv/3rdparty/lib/armeabi-v7a/libnative_camera_r4.0.0.so
/home/user/opencv/3rdparty/lib/armeabi-v7a/libnative_camera_r4.2.0.so
/home/user/opencv/3rdparty/lib/armeabi-v7a/libnative_camera_r4.1.1.so
/home/user/opencv/3rdparty/lib/armeabi-v7a/libnative_camera_r2.2.0.so
/home/user/opencv/3rdparty/lib/armeabi/libnative_camera_r2.3.3.so
/home/user/opencv/3rdparty/lib/armeabi/libnative_camera_r4.0.3.so
/home/user/opencv/3rdparty/lib/armeabi/libnative_camera_r3.0.1.so
/home/user/opencv/3rdparty/lib/armeabi/libnative_camera_r4.0.0.so
/home/user/opencv/3rdparty/lib/armeabi/libnative_camera_r4.2.0.so
/home/user/opencv/3rdparty/lib/armeabi/libnative_camera_r4.1.1.so
/home/user/opencv/3rdparty/lib/armeabi/libnative_camera_r2.2.0.so
/home/user/opencv/3rdparty/lib/x86/libnative_camera_r2.3.3.so
/home/user/opencv/3rdparty/lib/x86/libnative_camera_r4.0.3.so
/home/user/opencv/3rdparty/lib/x86/libnative_camera_r3.0.1.so
/home/user/opencv/3rdparty/lib/x86/libnative_camera_r4.2.0.so
/home/user/opencv/3rdparty/lib/x86/libnative_camera_r4.1.1.so
user#BEL-8WF4XW1:~$
I don't understand why it does work on the 32 bit system but not on the 64 bit system.
Can anyone help me understand?
I had to do 2 things after installing open cv (I am on a 64 bit ubuntu system):
step 1:
it needed /usr/local/lib added tot the path to get it working.
(when missing a link, use sudo locate <filename> to find where it is)
this is not default, but can be added in /etc/environment: gksudo gedit /etc/environment
(you need a reboot after that)
step 2:
After this it might still not run. Use this to config links:
sudo ldconfig
I hope this will solve your issue (especially the last step might do the trick)
It's not often two things I love so much come together to cause me so much annoyance (besides my kids). I've written a Haskell program at work that uses libraries like text, xml-enumerator, attoparsec-text, etc. I have it working properly on my Windows machine at work, my Ubuntu virtual machine at work (32-bit), my Ubuntu desktop (32-bit again) and an EC2 instance running Ubuntu (64-bit).
Our client is running CentOS 5.3, 64-bit. I can't for the life of me get this executable to run properly. I tried creating a static executable using:
ghc --make myprog.hs -optl-static -optl-pthread
But when I try to run that executable on the CentOS server, I get an error message:
openFile: invalid argument (Invalid argument)
I'm assuming this is related to the bug described here. I've tried compiling from both 32 and 64 bit Ubuntu, tried static and shared builds, nothing works (though I occasionally get segfaults instead of the above error message). I can try downloading CentOS 5.3 and creating a virtual machine for it, but it will take a while to download, and I'm not sure which version of GHC will work on it (I tried getting GHC 7 on their server, but I ran into a libc issue).
At this point, I've come up with a few possible approaches, but I'd like to avoid these if at all possible:
Rewrite in a different language (the thought of doing this in Java makes me queasy, though it could be a nice time to try out Cal/OpenQuark).
Maybe try out an alternate compiler, like jhc. But I'm not quite certain how to get started installing all the dependencies for this program in jhc; if people have experience and know that text/attoparsec/etc work in jhc, I'd love to hear it.
Hack of all hacks: build a Windows executable, install wine on their server and run it that way.
As a total aside, these are the situations where I really wish we had a JVM backend for GHC. I suppose I could try out LambdaVM as well. But I'd love to hear community advice on what to do here.
This simple example "works for me":
$ cat A.hs
main = print "yes"
$ ghc -O2 --make -static -optc-static -optl-static A.hs -fvia-C -optl-pthread
$ ldd A
not a dynamic executable
$ ./A
"yes"
(and I've used this process, via .cabal, to ship executables for clients in the past couple of years).
I think the best bet is to file bugs, and get this working. The IHG can also fund work like this, but I'm fairly sure the GHC team would consider this a high priority, if you're trying to ship products.
It is related to the old glibc library in CentOS. You have to compile with the same version of glibc as installed on CentOS.
I had exactly the same problem. Haskell executable compiled on arch (or ubuntu) won't run on CentOS. In my case though i was lucky, because our admin just removed CentOS and installed Arch for application server.
I found out the problem. It seems that the link to the Biohaskell page is accurate: this is a problem loading iconv. This occurs when calling openFile, but not when calling openBinaryFile. Since xml-enumerator uses the latter, it worked just fine. Switching over the rest of the code to use openBinaryFile instead (via Data.Enumerator.Binary.enumFile) got everything to work.
This is a good workaround for my use case, but the bug still exists.
When I run an executable I created, it uses the jvm.dll from C:\Windows\System32. But I want it to use the jvm.dll in C:\Program Files\Java\jdk1.6.0_17\jre\bin\server.
C:\Program Files\Java\jdk1.6.0_17\jre\bin\server is in my PATH environment variable.
Does anyone know how to accomplish this?
Thanks.
To solve this problem use same bit software mean if you are using 32bit Flex sdk then use 32 bit jdk and if you are using 64 bit Flex sdk then use 64 bit jdk
Is your jdk1.6.0_17 path before the windows\system32 path in your PATH variable?
Another thing to try would be to set "JAVA_HOME" to the root directory of your non-system32 JRE install.
c:\windows\system32\java.exe is just a hook
and it loads default jvm from program files
do you know which one is it loading in your case?