Cannot run an executable, ldd fails too
Hi all,
I've compiled and linked an executable to isolate a certain compiler behavior. The program is a mix of Free Pascal and GNU C++. I cannot run it! When I run ./ctest I get: -bash: ./ctest: No such file or directory When I do ldd ./ctest I get /usr/bin/ldd: line 117: ./ctest: No such file or directory The file is there and it's an executable. To check, I did file ./ctest and got: ./ctest: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped As a further check, I did readelf -l ctest And got: Quote:
Any ideas, please? What could cause an error message like this from a perfectly good executable? |
hey,
i don't exactly know the reason, but can you check that the file has execute permissions set ? |
Quote:
and almost sure you haven't /usr/lib/libc.so.1 on your system. Did you copied it from Solaris ? |
Quote:
Where does the interpreter come from? Is it a per-executable setting, or a systemwide one? I did not copy the executable from anywhere - I built it from sources which I wrote: Save as ctest.pas: Quote:
Quote:
Quote:
|
The interpreter thing is definitely fishy.
If I build C++ alone or Pascal alone, the interpreter in the executable is /lib/ld-linux.so.2. If I compile a mix, the interpreter becomes /usr/lib/libc.so.1, which I don't have (locate can't find). If I compile Pascal alone but specify -k-lstdc++, that's also the case. So the issue is somewhere in the libstdc++.so. That library sits in /usr/lib, and it's actually a symlink to a symlink to libstdc++.so.6.0.10 in the same directory. When I compile C++ with verbose linking, I see it finds libstdc++ under /usr/lib/gcc/i486-linux-gnu/4.1.3/. That one is a symlink to the same, so the result shouldn't be any different. During the linking stage, both in C++ builds and in mixed C++/Pascal builds, there's a message that "ld-linux.so.2 needed by /usr/bin/../lib/libstdc++.so", and it finds that file under /lib/. Any ideas, please? |
Quote:
Code:
INTERP 0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R 0x1 While linker decided to put this one into your executable I have no idea. Could you post output of verbose linking, may be it'll help understand what problem is |
It's quite long... :)
Quote:
|
Hi!
I read your post completely, i had experienced this same error when i tried to compile a bunch of C code with GCC 4.2.1 Under a RHEL 5 Box and solved the problem using the following option when invoking LD: --dynamic-linker /lib/ld-linux.so.2 That options just forces LD to use that Dynamic Loader, instead of the default that probably is /usr/lib/libc.so.1 and is wrong. Just add that option when you call to LD ( for instance ld --dynamic-linker /lib/ld-linux.so.2 bla bla bla ) and voila!!! that should resolve your problem and get it away!! Hope this can help you |
All times are GMT -5. The time now is 09:23 AM. |