public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: ng@piments.com
To: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Cc: crossgcc@sourceware.org
Subject: Re: how to get target ldd ?
Date: Tue, 09 Jun 2009 22:17:00 -0000	[thread overview]
Message-ID: <4A2EDF5A.9080404@piments.com> (raw)
In-Reply-To: <200906071856.48287.yann.morin.1998@anciens.enib.fr>

Yann E. MORIN wrote:
> Peter,
> All,
> 
> On Saturday 06 June 2009 09:09:02 peter wrote:
>> I am having problems with a busybox ARM target I have build using ct-ng. 
>>   None of the executables , including busybox, seem to work unless I 
>> build them static.
> 
> What's the symptom ?
> Do they segfault ?
> Can you run a statically linked hello world ? A dynamic one ?
> What does it say on the console?
> Using glibc or uClibc ?
> ...
> 
> You did not give enough info to diagnose the problem...
> 
>> Is there a way to get ldd for the target system out of ct-ng?
> 
> Look in the archives, this has already been discussed...
> 
> The /problem/ with ldd (the one in glibc, at least) is that it tries to
> _run_ the dynamic linker /lib/ld-xxx.so with some environment variables
> set, and this will print the libraries it finds _at_runtime_.
> 
> Obviously, you don't want to run your ARM dynamic linker on your dev
> machine, as this most probably is some kind os x86.
> 
> If using populate as per your previous posts, what does populate -v says?
> 
> Regards,
> Yann E. MORIN.
> 

Thanks Yann, Dan,

I did not give more details of the problem because I thought ldd would 
enable me to see where the problem lay. Sadly not. I copied the sys-root 
copy of ldd and it gives me the same silliness as the other commands.

# which ldd
/usr/bin/ldd
# ldd
-sh: ldd: not found
# ls -ail `which ldd`
3273877 -r-xr-xr-x    1 root     root         5583 Jun  8  2009 /usr/bin/ldd

So it's there, it's found by which, but "not found". Clearly this is 
just busybox's challenged error handling spewing garbage. The question 
is how to debug what is really happending.

This error is helpful in itself since it's not even a binary, it's a 
script. Binaries give :

-sh: gnuplot: Permission denied

even though they have x permissions and are being invoked by root.

# which gnuplot
/usr/bin/gnuplot

# `which gnuplot`
-sh: /usr/bin/gnuplot: Permission denied

# ls -ail `which gnuplot`
3272843 -rwxr-xr-x    1 root     root      2074273 Jun  2  2009 
/usr/bin/gnuplot

Following Dan's suggestion got not more information: (unless getting the 
same output with the trace IS more information)
# LD_TRACE_LOADED_OBJECTS=1  gnuplot
-sh: gnuplot: Permission denied



Busybox static works , bb with normal dyn linking : permission denied.



 > If using populate as per your previous posts, what does populate -v says?

Tar bleats about some files in /etc having "improbable" datestamp, circa 
1/1/1970. This does not seem to be an error though. After that it finds 
the expected libs , oopies them , then starts "looping". This just 
reports libs to be already present. This seems to be in order.

LD_TRACE_LOADED_OBJECTS=1  hello.stat
Hello world!

# LD_TRACE_LOADED_OBJECTS=1  hello.dyn
-sh: hello.dyn: Permission denied


So either ld loads but can't link or there is a broken lib...

bash-4.0#file /back/ts/root-image/lib/libc.so.6
/back/ts/root-image/lib/libc.so.6: ELF 32-bit LSB shared object, ARM, 
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 
2.6.29, not stripped

# readelf -a /back/ts/root-image/lib/libc.so.6
...
Version needs section '.gnu.version_r' contains 1 entries:
  Addr: 0x0000000000012520  Offset: 0x012520  Link: 4 (.dynstr)
   000000: Version: 1  File: ld-linux.so.3  Cnt: 2
   0x0010:   Name: GLIBC_2.4  Flags: none  Version: 10
   0x0020:   Name: GLIBC_PRIVATE  Flags: none  Version: 9

Notes at offset 0x00000194 with length 0x00000020:
   Owner         Data size       Description
   GNU           0x00000010      NT_GNU_ABI_TAG (ABI version tag)
Attribute Section: aeabi
File Attributes
   Tag_CPU_name: "4T"
   Tag_CPU_arch: v4T
   Tag_ARM_ISA_use: Yes
   Tag_ABI_PCS_wchar_t: 4
   Tag_ABI_FP_denormal: Needed
   Tag_ABI_FP_exceptions: Needed
   Tag_ABI_FP_number_model: IEEE 754
   Tag_ABI_align8_needed: Yes
   Tag_ABI_align8_preserved: Yes, except leaf SP
   Tag_ABI_enum_size: int


I'm short on ideas now.

Thx

--
For unsubscribe information see http://sourceware.org/lists.html#faq

  reply	other threads:[~2009-06-09 22:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-06  7:09 peter
2009-06-06 17:09 ` Dan Wilder
2009-06-07 16:56 ` Yann E. MORIN
2009-06-09 22:17   ` ng [this message]
2009-06-10  6:01     ` Yann E. MORIN
2009-06-10  7:08       ` ng
2009-06-10 21:29         ` ng
2009-06-11 20:39           ` Yann E. MORIN
2009-06-12  8:03             ` ng
2009-06-10  8:34 Nebojša Ćosić
2009-06-10 14:48 ` Dan Wilder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A2EDF5A.9080404@piments.com \
    --to=ng@piments.com \
    --cc=crossgcc@sourceware.org \
    --cc=yann.morin.1998@anciens.enib.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).