Cannot dynamically load executable

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Cannot dynamically load executable

Matt Eisan
I was trying to load my own custom binary, and I used some sample code from the PIL 2nd edition, and edited a bit because I using Lua 5.2. 

I am using Ubuntu 12.04 64-bit, and I managed to compile the binary just fine, but when I call require to load it, I get the error: 

Lua 5.2.0  Copyright (C) 1994-2011 Lua.org, PUC-Rio
> require'test'
error loading module 'test' from file './test.so':
./test.so: cannot dynamically load executable
stack traceback:
[C]: in ?
[C]: in function 'require'
stdin:1: in main chunk
[C]: in ?

I have no idea as to why this would happen, I've spent hours looking around google to no avail.

I have attached the code I am using, and I compile with GCC using g++ dir.cpp -o test.so -llua

Any help is greatly appreciated.

dir.cpp (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cannot dynamically load executable

Drake Wilson
Quoth Matt Eisan <[hidden email]>, on 2013-04-24 20:42:40 -0400:
> I have attached the code I am using, and I compile with GCC using g++
> dir.cpp -o test.so -llua
[...]
> int main() {
> return 0;
> }

No, you want to create a shared library, not a main executable file.  Use g++
-shared and get rid of main(), to start with.  Nor, I think, will it work with
the name 'test.so' but an entrypoint function name of luaopen_mylib; the
expected load name should match the luaopen_* entrypoint and the .so basename,
as in foo.so loaded with require('foo') defining the C function luaopen_foo.

Also, all of the functions you're planning to cast to lua_CFunction (such as
l_dir), as well as the luaopen_* entrypoint, should be extern "C", if I'm not
mistaken.  (You'll also want to consider exceptions if you're interfacing to
C++, but that can be later.)

   ---> Drake Wilson

Reply | Threaded
Open this post in threaded view
|

Re: Cannot dynamically load executable

Matt Eisan
Thanks for the reply, Drake.  

When I tried adding -shared to the compile line, I got a strange error: 

matt@matt-BM412AA-ABA-CQ5600Y:~/Downloads/lua-5.2.0/src$ g++ dir.cpp -o test.so -llua -shared
/usr/bin/ld: /usr/local/lib/liblua.a(lapi.o): relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/liblua.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

It says to recompile with fPIC (whatever that is?), but I tried that and still got the same exact error.


On Wed, Apr 24, 2013 at 9:07 PM, Drake Wilson <[hidden email]> wrote:
Quoth Matt Eisan <[hidden email]>, on 2013-04-24 20:42:40 -0400:
> I have attached the code I am using, and I compile with GCC using g++
> dir.cpp -o test.so -llua
[...]
> int main() {
>       return 0;
> }

No, you want to create a shared library, not a main executable file.  Use g++
-shared and get rid of main(), to start with.  Nor, I think, will it work with
the name 'test.so' but an entrypoint function name of luaopen_mylib; the
expected load name should match the luaopen_* entrypoint and the .so basename,
as in foo.so loaded with require('foo') defining the C function luaopen_foo.

Also, all of the functions you're planning to cast to lua_CFunction (such as
l_dir), as well as the luaopen_* entrypoint, should be extern "C", if I'm not
mistaken.  (You'll also want to consider exceptions if you're interfacing to
C++, but that can be later.)

   ---> Drake Wilson


Reply | Threaded
Open this post in threaded view
|

Re: Cannot dynamically load executable

Drake Wilson
Quoth Matt Eisan <[hidden email]>, on 2013-04-24 21:34:08 -0400:

> Thanks for the reply, Drake.
>
> When I tried adding -shared to the compile line, I got a strange error:
>
> matt@matt-BM412AA-ABA-CQ5600Y:~/Downloads/lua-5.2.0/src$ g++ dir.cpp -o
> test.so -llua -shared
> /usr/bin/ld: /usr/local/lib/liblua.a(lapi.o): relocation R_X86_64_32
> against `luaO_nilobject_' can not be used when making a shared object;
> recompile with -fPIC
> /usr/local/lib/liblua.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status

Yes, that's right.  You need position-independent code on Linux x86-64 for
shared libraries, and also you shouldn't be linking the Lua core into the
shared library, so no -llua (and it seems customary to put the -shared at
the beginning of the command line, though I'm not sure whether it matters
for GCC); that's trying to pull in an entire static Lua, which is wrong.

You should read http://lua-users.org/wiki/BuildingModules if you haven't
already.

   ---> Drake Wilson

Reply | Threaded
Open this post in threaded view
|

Re: Cannot dynamically load executable

Philipp Janda
In reply to this post by Matt Eisan
Am 25.04.2013 03:34 schröbte Matt Eisan:

> Thanks for the reply, Drake.
>
> When I tried adding -shared to the compile line, I got a strange error:
>
> matt@matt-BM412AA-ABA-CQ5600Y:~/Downloads/lua-5.2.0/src$ g++ dir.cpp -o
> test.so -llua -shared
> /usr/bin/ld: /usr/local/lib/liblua.a(lapi.o): relocation R_X86_64_32
> against `luaO_nilobject_' can not be used when making a shared object;
> recompile with -fPIC
> /usr/local/lib/liblua.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
>
> It says to recompile with fPIC (whatever that is?), but I tried that and
> still got the same exact error.

That's because the error is in a static library which you obviously
didn't recompile. But luckily you probably don't need this library
anyway (if you compiled Lua with the default flags on Linux), so try
adding -fPIC and removing -llua.

Btw., "PIC" means "position independent code", and refers to code that
can end up at different addresses at runtime due to being loaded as a
shared library.

Philipp




Reply | Threaded
Open this post in threaded view
|

Re: Cannot dynamically load executable

Matt Eisan
In reply to this post by Drake Wilson
Thank you, I got it working now and I'll be sure to read that. Thank you so much, I've been trying to get this working for over a week now.


On Wed, Apr 24, 2013 at 9:57 PM, Drake Wilson <[hidden email]> wrote:
Quoth Matt Eisan <[hidden email]>, on 2013-04-24 21:34:08 -0400:
> Thanks for the reply, Drake.
>
> When I tried adding -shared to the compile line, I got a strange error:
>
> matt@matt-BM412AA-ABA-CQ5600Y:~/Downloads/lua-5.2.0/src$ g++ dir.cpp -o
> test.so -llua -shared
> /usr/bin/ld: /usr/local/lib/liblua.a(lapi.o): relocation R_X86_64_32
> against `luaO_nilobject_' can not be used when making a shared object;
> recompile with -fPIC
> /usr/local/lib/liblua.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status

Yes, that's right.  You need position-independent code on Linux x86-64 for
shared libraries, and also you shouldn't be linking the Lua core into the
shared library, so no -llua (and it seems customary to put the -shared at
the beginning of the command line, though I'm not sure whether it matters
for GCC); that's trying to pull in an entire static Lua, which is wrong.

You should read http://lua-users.org/wiki/BuildingModules if you haven't
already.

   ---> Drake Wilson