LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 11-15-2009, 10:15 PM   #1
bozox
LQ Newbie
 
Registered: Oct 2008
Posts: 20

Rep: Reputation: 0
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:
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?

Last edited by bozox; 11-15-2009 at 10:18 PM.
 
Old 11-16-2009, 12:10 AM   #2
vijaush
LQ Newbie
 
Registered: Feb 2007
Posts: 8

Rep: Reputation: 0
hey,
i don't exactly know the reason, but can you check that the file has execute permissions set ?
 
Old 11-16-2009, 12:21 AM   #3
Valery Reznic
ELF Statifier author
 
Registered: Oct 2007
Posts: 676

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by bozox View Post
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 ?
 
Old 11-16-2009, 08:16 AM   #4
bozox
LQ Newbie
 
Registered: Oct 2008
Posts: 20

Original Poster
Rep: Reputation: 0
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++
 
Old 11-16-2009, 11:37 AM   #5
bozox
LQ Newbie
 
Registered: Oct 2008
Posts: 20

Original Poster
Rep: Reputation: 0
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?
 
Old 11-17-2009, 02:03 PM   #6
Valery Reznic
ELF Statifier author
 
Registered: Oct 2007
Posts: 676

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by bozox View Post
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
 
Old 11-17-2009, 08:24 PM   #7
bozox
LQ Newbie
 
Registered: Oct 2008
Posts: 20

Original Poster
Rep: Reputation: 0
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.
 
Old 12-11-2009, 06:20 PM   #8
gwrba
LQ Newbie
 
Registered: Dec 2009
Posts: 1

Rep: Reputation: 0
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
ldd on cross-compiled executable ranthal Linux - Software 2 10-19-2009 05:03 PM
cannot get an executable to run... disruptive Linux - Newbie 5 03-04-2008 11:18 AM
"list dynamic dependency" of an executable using command other than "ldd" Amrita@3086 Solaris / OpenSolaris 3 04-04-2007 04:56 AM
Ubuntu 5.10 -> 6.06: diversion of /usr/bin/ldd to /usr/bin/ldd.amd64 by ia32-libs HellSpawn Linux - Software 2 06-04-2006 09:18 PM
an executable that does not run jgoggel Programming 2 07-22-2004 07:54 PM


All times are GMT -5. The time now is 02:34 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration