[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ld.real] Relocations in generic ELF (EM: 3)
- From: Ico <lua@...>
- Date: Thu, 25 Nov 2010 21:47:01 +0100
* On 2010-11-25 Gilles Ganault <email@example.com> wrote :
> On Thu, 25 Nov 2010 20:56:50 +0100, Ico <firstname.lastname@example.org> 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.