Re: What all should I take care while compiling and running?

[Pramod P K <pra dot engr at gmail dot com>]

Hi,

>Question to the original poster -- what is the binary format of your >a.out
>file?  If it truly is in a.out format, then was your kernel
configured to >handle
>the a.out binary format?

Its ELF .
Yeah... sure, coz I can run the a.out of the same program; compiled
using the existing (old) GCC in the TARGET.

> > >>  Is the 'x' bit set?  Is there a problem with nfs user/group perms?

those things are OK.

> > if you link your program statically then it should work ok. Have you
> > tried that?

yeah...
I used:
arm-9tdmi-linux-gnu-gcc  -static  hello.c
am I correct?
Now I hv  attached 2 a.out (one statically linked)
for the hello.c prog comes with crosstool-0.38

I used " testhello.sh " to test my target arm-9tdmi-linux-gnu.
This generated 4 files:
arm-9tdmi-linux-gnu-hello
arm-9tdmi-linux-gnu-hello2
arm-9tdmi-linux-gnu-hello2-static
arm-9tdmi-linux-gnu-hello-static

for static option it gives : " illegal instruction "
for shared option it gives : " segmentation fault "
for none of these options: " ./a.out not found "

Thanx n Regards,
Pramod P K



On 11/9/05, Chuck Meade <chuckmeade@mindspring.com> wrote:
> > >>>Hi,
> > >>>I created crosstool for arm-9tdmi-linux-gnu.  I compiled a simple program
> > >>>using arm-9tdmi-linux-gnu-gcc.
> > >>>(My target board has already  Kernel-2.6.10 and a compiler for older
> > >>>versions of gcc & glibc)
> > >>>
> > >>>I mount:  mount -o nolock,rsize=1500,wsize=1500 -t nfs
> > >>>161.85.96.148:/home/pramod/crosstool  /mnt/test
> > >>>
> > >>>Ive simply used ./a.out.
> > >>>But its giving " sh:./a.out not found "
> > >>>even when there is compiled a.out in /mnt/test.
> > >>>
> > >>>
> > >>  Is the 'x' bit set?  Is there a problem with nfs user/group perms?
> > >>
> > >>    cheers,
> > >>      DaveK
> > >>
> > >>
> > >
> > >I recently saw a problem with the same behavior.  The issue is (likely) that
> > >you are using a different compiler and glibc version for your app than the
> > >rest of your target code was built with.
> > >
> > >
> > This is what is happening. It is glibc version only which causes these
> > kind of problem
> > if you link your program statically then it should work ok. Have you
> > tried that?
>
> I immediately suspected the tool version problem, and using a consistent
> compiler & glibc fixed this for me.  So no, I did not go back and try to
> link statically.  I believe that there are other things that could cause
> this that a static link would not fix.  Couldn't this be a syscall numbering
> issue, or a binary format issue?  Even statically linked, if his kernel
> cannot understand the binary format, it will fail.  I don't know how consistent
> syscall numbering is across major tool versions, but if those change, that
> would cause havoc as well.
>
> Question to the original poster -- what is the binary format of your a.out
> file?  If it truly is in a.out format, then was your kernel configured to handle
> the a.out binary format?  Use your cross binutils and objdump your a.out file.
> Try to strace a.out on your target.
>
> You may send me (if it is small, i.e. hello world) your a.out file and I'll
> see if I can tell you anything about it.
>
> Chuck
>
>
>


--
----------------------------------------------------------------
  PRAMOD P. K., <pra.engr@gmail.com>

  CDMA: 91- 9242195490.
----------------------------------------------------------------

Attachment: hello.c
Description: Text document

Attachment: arm-9tdmi-linux-gnu-hello
Description: Binary data

Attachment: arm-9tdmi-linux-gnu-hello-static
Description: Binary data

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com