Topic: Unable to load dynamic executable

[Rosencrantz]

After I got everything compiled on my new Athlon 64 at home I got this error.
Hrm... any thoughts?

Code: [Select]

Attempt to load plugin 'crystalspace.device.joystick.linux' failed
DLERROR (/home/ryan/current/precursors/pcnetworkentity.so): /home/ryan/current/precursors/pcnetworkentity.so: cannot dynamically load executable
SCF_WARNING: factory returned a null instance for cel.pcfactory.pcnetworkentity
        if error messages are not self explanatory, recompile CS with CS_DEBUG

crystalspace.pluginmgr.loadplugin:
  could not load plugin 'cel.pcfactory.pcnetworkentity'

crystalspace.cel.physicallayer:
  CEL 'cel.pcfactory.pcnetworkentity' property class factory plugin missing!
gne.Precursors:  Error loading cel.pcfactory.pcnetworkentity factor


Code: [Select]

ryan@darth-puter ~ $ uname -a
Linux darth-puter 2.6.18-gentoo-r4 #1 SMP Thu Dec 21 15:47:42 Local time zone must be set--see zic  x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ GNU/Linux


[Morgul]

Make sure everything built correctly. (Especially RakNet.)

[Rosencrantz]

There were some warnings when RakNet was compiling both here at work and at home. Not sure if they're the same warnings or not, mostly just virtual destructor warnings and some signed/unsigned stuff in RakPeer (on x86).
One thing I forgot to check was the executable format of the pcnetworkentity.so file. Ooops, must've been tired.

--Rosencrantz

[Rosencrantz]

Ok, found why it won't load.

Code: [Select]

open("/home/ryan/current/precursors/pcnetworkentity.so", O_RDONLY) = 31
read(31, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\0\254@\0"..., 832) = 832
                                          ^
open("/home/ryan/current/cel/pfmechanics.so", O_RDONLY) = 31
read(31, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\206\2\0"..., 832) = 832
                                          ^

All of ther other .so's are the same up to the ">".

Does anyone have any idea what this means, or why it might be different? Changing the \2 to a \3 makes it load, but it still segfaults when it tries to use the network plugin.

[Rosencrantz]

Minor update:

RakNet does work on 64-bit linux, or at least the latest version does. I downloaded it, compiled it and the test chat program, which works fine (Other than not being robust enough to accept localhost as a valid IP to connect to).

[Morgul]

Well, then I guess the only thing to do, is to put that version in precursors, and see if it works. All you should need to do is to put the headers in include/raknet and everything in source wherever the current raknet source is in our repo.

[Rosencrantz]

Well, then I guess the only thing to do, is to put that version in precursors, and see if it works. All you should need to do is to put the headers in include/raknet and everything in source wherever the current raknet source is in our repo.

That was my thought as well, but no go. Still the most up to date version in the repo.
I'll fiddle around some and see what else I can find, if anything.

[Morgul]

Regarding the 'fix' you found of manually putting '-shared' in the gcc line; that makes it a shared library. IIRC, the way to do this via configure is --enable-shared.

In thinking about this, -shared might imply -fPIC, which might be the actual flag that's needed. Unsure of that, and I don't have to time to see if we're building with -fPIC normally. I think that the problem is it's not position independent, and breaks on 64 bit systems somehow. Again, this is just ignorant speculation.

--Chris

[Rosencrantz]

Well I found how to get the -shared option added in correctly. I used the Crystal Space External Application configure script generator and diffed some of the jam rules until I found something useful. Found the appropriate jam file, tried it out on 32-bit, and commited it. Works fine on my work box, I'll see if it actually fixes the problem when I get home.

[Rosencrantz]

Ok, there is something here at work amidst the jamfiles that is *very* *very* wierd.

Exhibit A) On kashmir, "jam -d x pcnetworkentity" with rev 1114 shows that it is being compiled with -shared. This is good.

Exhibit B) On my amd64 "jam -d x pcnetworkentity" with rev 1114 shows that it is being compiled without -shared. This is not good.

Exhibit C) http://gne.pastebin.ca/308553. Causes everything to work normally, but I've no idea if that's safe to change.

Any thoughts?

[Rosencrantz]

Found it, fixed it, and commited. Updated the mk/autoconf scripts. They were setting the PLUGIN.LDFLAGS to -shared on x86, but not amd64. Updating from the latest CS Ext Package stuff worked. Now there's a new problem, *sigh* (only with networking though).