Cannot run an executable, ldd fails too

bozox · 11-15-2009, 10:15 PM

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:

Elf file type is EXEC (Executable file)
Entry point 0x805faa0
There are 6 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4
INTERP 0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R 0x1
[Requesting program interpreter: /usr/lib/libc.so.1]
LOAD 0x000000 0x08048000 0x08048000 0x17bac 0x17bac R E 0x1000
LOAD 0x018000 0x08060000 0x08060000 0x03ee8 0x05b04 RW 0x1000
DYNAMIC 0x018004 0x08060004 0x08060004 0x000c0 0x000c0 RW 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .plt .text .rodata .eh_frame
03 .ctors .dynamic .got.plt .data .bss
04 .dynamic
05

In other words, the file appears proper. Now, earlier this week I did some fidling with libstdc++.so, which this file depended on. But I thought that lack of a shared library would cause a specific error message, something like "libstdc++ not found".

Any ideas, please? What could cause an error message like this from a perfectly good executable?

vijaush · 11-16-2009, 12:10 AM

hey,
i don't exactly know the reason, but can you check that the file has execute permissions set ?

Valery Reznic · 11-16-2009, 12:21 AM

Quote:

Originally Posted by bozox

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:

In other words, the file appears proper. Now, earlier this week I did some fidling with libstdc++.so, which this file depended on. But I thought that lack of a shared library would cause a specific error message, something like "libstdc++ not found".

Any ideas, please? What could cause an error message like this from a perfectly good executable?

Usually interpreter on linux is /lib/ld-linux.so.2
and almost sure you haven't /usr/lib/libc.so.1 on your system.

Did you copied it from Solaris ?

bozox · 11-16-2009, 08:16 AM

Quote:

ls -l ctest
-rwxr-xr-x 1 seva seva 115424 2009-11-15 18:12 ctest

The system is Debian Lenny, recently upgraded from Etch with some interruptions.

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:

program ctest;

procedure Hello; cdecl; external name 'Hello';
{$L chello.o}

begin
Hello;
end.

Save as chello.cpp:

Quote:

#include <iostream>

extern "C"
{
void *__dso_handle = 0;

void Hello(void)
{
std::cout << "Hello from C++" << std::endl;
}
}

Build as follows:

Quote:

g++ -c chello.cpp
fpc ctest.pas -k-lstdc++

bozox · 11-16-2009, 11:37 AM

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?

Valery Reznic · 11-17-2009, 02:03 PM

Quote:

Originally Posted by bozox

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?

interpreter (as shown by readelf

Code:

INTERP 0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R 0x1
[Requesting program interpreter: /usr/lib/libc.so.1]

is just string written in the specific place in the ELF file,
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

bozox · 11-17-2009, 08:24 PM

It's quite long...

Quote:

seva@sandbox:~$ fpc ctest.pas -k-lstdc++ -k-verbose
Free Pascal Compiler version 2.2.2 [2008/07/30] for i386
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for i386
Compiling ctest.pas
Linking ctest
GNU ld (GNU Binutils for Debian) 2.18.0.20080103
Supported emulations:
elf_i386
i386linux
elf_x86_64
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
"elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR("/usr/i486-linux-gnu/lib32"); SEARCH_DIR("/usr/local/lib32"); SEARCH_DIR("/lib32"); SEARCH_DIR("/usr/lib32"); SEARCH_DIR("/usr/i486-linux-gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0x08048000); . = 0x08048000 + SIZEOF_HEADERS;
.interp : { *(.interp) }
.note.gnu.build-id : { *(.note.gnu.build-id) }
.hash : { *(.hash) }
.gnu.hash : { *(.gnu.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.dyn :
{
*(.rel.init)
*(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
*(.rel.fini)
*(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
*(.rel.data.rel.ro* .rel.gnu.linkonce.d.rel.ro.*)
*(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
*(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
*(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
*(.rel.ctors)
*(.rel.dtors)
*(.rel.got)
*(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
}
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
}
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
{
KEEP (*(.init))
} =0x90909090
.plt : { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
KEEP (*(.text.*personality*))
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
} =0x90909090
.fini :
{
KEEP (*(.fini))
} =0x90909090
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1 : { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN (CONSTANT (MAXPAGESIZE)) - ((CONSTANT (MAXPAGESIZE) - .) & (CONSTANT (MAXPAGESIZE) - 1)); . = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE));
/* Exception handling */
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
}
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
PROVIDE_HIDDEN (__fini_array_end = .);
}
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
/* We don't want to include the .ctor section from
the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
.dtors :
{
KEEP (*crtbegin.o(.dtors))
KEEP (*crtbegin?.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
}
.jcr : { KEEP (*(.jcr)) }
.data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro* .gnu.linkonce.d.rel.ro.*) }
.dynamic : { *(.dynamic) }
.got : { *(.got) }
. = DATA_SEGMENT_RELRO_END (12, .);
.got.plt : { *(.got.plt) }
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
KEEP (*(.gnu.linkonce.d.*personality*))
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
_edata = .; PROVIDE (edata = .);
__bss_start = .;
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
.bss section disappears because there are no input sections.
FIXME: Why do we need it? When there is no .bss section, we don't
pad the .data section. */
. = ALIGN(. != 0 ? 32 / 8 : 1);
}
. = ALIGN(32 / 8);
. = ALIGN(32 / 8);
_end = .; PROVIDE (end = .);
. = DATA_SEGMENT_END (.);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
/* DWARF 3 */
.debug_pubtypes 0 : { *(.debug_pubtypes) }
.debug_ranges 0 : { *(.debug_ranges) }
.gnu.attributes 0 : { KEEP (*(.gnu.attributes)) }
/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) }
}

==================================================
attempt to open ./libstdc++.so failed
attempt to open ./libstdc++.a failed
attempt to open /usr/bin/../lib/libstdc++.so succeeded
-lstdc++ (/usr/bin/../lib/libstdc++.so)
attempt to open link.res succeeded
opened script file link.res
attempt to open ctest.o succeeded
ctest.o
attempt to open zhello.o succeeded
zhello.o
attempt to open /usr/lib/fpc/2.2.2/units/i386-linux/rtl/system.o succeeded
/usr/lib/fpc/2.2.2/units/i386-linux/rtl/system.o
attempt to open /usr/lib/fpc/2.2.2/units/i386-linux/rtl/si_prc.o succeeded
/usr/lib/fpc/2.2.2/units/i386-linux/rtl/si_prc.o
libm.so.6 needed by /usr/bin/../lib/libstdc++.so
found libm.so.6 at /lib/libm.so.6
libc.so.6 needed by /usr/bin/../lib/libstdc++.so
found libc.so.6 at /lib/libc.so.6
ld-linux.so.2 needed by /usr/bin/../lib/libstdc++.so
found ld-linux.so.2 at /lib/ld-linux.so.2
libgcc_s.so.1 needed by /usr/bin/../lib/libstdc++.so
found libgcc_s.so.1 at /lib/libgcc_s.so.1
8 lines compiled, 0.5 sec

By the way, I found a way to override the error by providing the LD --dynamic-linker option explicitly. A whole new set of issues appeared, but that's beside the point.

gwrba · 12-11-2009, 06:20 PM

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