lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

* On 2010-11-25 Gilles Ganault <> wrote  :

> On Thu, 25 Nov 2010 20:56:50 +0100, Ico <> 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.