Re: [ld.real] Relocations in generic ELF (EM: 3)

[Ico <lua@...>]

* On 2010-11-25 Gilles Ganault <gilles.ganault@free.fr> wrote  :

> On Thu, 25 Nov 2010 20:56:50 +0100, Ico <lua@zevv.nl> wrote:
> >This last line often means the object file is for the wrong
> >architecture so the linker does not know how to handle this. Are you
> >sure all objects are made with the bfin-uclinux-gcc ? Maybe some of the
> >.o's were built earlier with your native compiler ? 
> 
> My hero! :-) I did have .o from previous attempts, which had been
> compiled for the x86, and I totally forgot about removing them.
> 
> Then, to give it a try, I dowloaded "lua" and "luac" on the device,
> but can't get a shell:
> 
> /tmp> ls -al
> -rwxr-xr-x    1 root     root       523897 Nov 25 21:24 lua
> -rwxr-xr-x    1 root     root       300960 Nov 25 21:27 luac
> 
> /tmp> lua
> lua: not found

That's because the current directory '.' is usually not in your $PATH,
so that's ok. If you would place the binary in /bin, you'd be able to
run it with just 'lua'

> /tmp> ./lua
> lua: applet not found

That's no good. The message 'applet not found' probably comes from
busybox, the 'all purpose unix swiss army knife', a hundred tools in one
binary, which likely also provides the shell you're using.

Strange that busybox would show this message, this usually happens when
a symling to busybox with an unknown name is called.

You might want to try to build a statically linked lua binary to make
sure no other dependencies are needed for running it. You could
redo the latest stage of building the binary by hand, and add the
'-static' flag. Something like

  your-cross-gcc -static -o lua lua.o liblua.a

might do it.


-- 
:wq
^X^Cy^K^X^C^C^C^C