Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Razor]

I'm having a problem integrating OIS with my OGRE app.  All the demos seem to compile without problems, but my own app fails during linking with an undefined reference to 'OIS::InputManager::destroyInputSystem()'  I've tried searching the forums and googling, but come up empty.

I initially had the problem with  0.4.0, upgraded to 0.5.0 hoping it would solve the problem, but it didn't.  I have tried rebuilding the lib with the same results.  I'm pretty sure everything is set up properly.  I don't get any compile errors, nor do I get any other linker errors.  

My system is:
Ubuntu 5.10
gcc 4.0.2
Ogre Dagon
OIS 0.5.0 static lib (also tried 0.4.0 static)

What am I doing wrong?
Any help would be greatly appreciated

[pjcast]

Interesting. If you comment out that use of destroyInputSystem() can you then compile? or do you get more unresolved externals?

If you get more unresolved externals (and the fact that you say the demos work) you are probably not linking against the libOIS. How are you bringing in OIS? Through pkgconfig?

[Razor]

If I comment out that line it compiles and links fine.  I've tried using it both as ois->destroyInputSystem() and OIS::InputManager::destroyInputSystem() with the same results.  (ois is declared OIS::InputManager * and created with createInputSystem())

I don't use pkg-config directly as I use jam for my build system and I haven't found a way to do something similar to makes ${shell ... }, however the commands to bring in OIS are a direct copy and paste from pkg-configs output
(-I/usr/local/include/OIS -L/usr/local/lib -lOIS)

[pjcast]

Hmm, don't quite know what is going on then. Both of those methods (createInputSystem() and destroyInputSystem() are identical in that they are both static members of the same class, and definately included in OISInputManager.cpp. I do not know off the top of my head what the command is, but if you could dump out the symbols from libOIS and inspect to see if it is indeed defined inside or not.

[Razor]

Oops.  I should double check things before posting  :oops:

The call to createInputSystem was commented out.  Uncommenting it gives me another undefined reference.  I can call createInputObject and destroyInputObject without causing linker errors.  It seems the problem lies with static class members somehow...

I'm not sure how to dump out the symbols.  Running strings on the lib does show references to destroyInputSystem and createInputSystem, but that's not necessarily to say that they are properly defined symbols.

I tried googling it, and all I could come up with was readelf.  readelf does show reference to both create and destroy InputSystem functions.

I will keep looking for the command to dump the symbols.

EDIT: I don't have a force feedback joystick hooked up, so I can't check FFConsoleApp, but I did check ConsoleApp in the demo directory, just to be sure, and it does indeed compile and run as expected. It was compiled with the same system and compiler as the app I'm trying to build.  Weird.  I'm don't even have a guess as to what's going on.

[pjcast]

Now that I'm thinking a little more about this. You said the demos were compiling fine (and I assuem they run fine). The symbol should infact be there. Perhaps (I'm not sure) the libOIS that the demos link against (they link directly to ois/src/libOIS) is not the one being installed on your system.. sounds wacky, but hmm. You could try hard coding your path to the same exact lib that the demos link to (in ois/src/libOIS).

[Razor]

I tried copying the lib from ois/src to the install directory by hand, but it didn't work.

After playing with the linker command line a little bit, I found a workaround/resolution.  If I change the order of the linker command so that -lOIS is the last option to be listed, it works.  I'm not entirely sure why it works, but I think I get the idea from reading the ld man page.  The libs are only examined once, in the order they are listed on the command line.  Any unresolved symbols from files later in the command line won't get resolved.  What I don't get at all is why some symbols were found in the lib, while others weren't.

Thanks for the help resolving this.

[pjcast]

Interesting, I've never heard that before. Sounds pretty lame. I know VC does multiple passes to resolve symbols.

Anyway, glad you at least found a work around. I have been thinking about moving libOIS to build as a Shared lib on linux instead of a static lib. This may make this error not happen anymore (possibly) as a result. THe benifits of a shared lib: I can link the x11 libs right to the lib instead of having the app itself do that, and it can be shared among other apps that want to use OIS, and it would be easier to swap out.

[Razor]

Yeah, I know VC does multiple passes.  I always just assumed gcc did too.  I guess not.

I'm not sure if a shared lib would solve the problem or not, but it's possible it would.  I know Ogre uses plenty of static members for singletons, and I've never run into this problem with Ogre.  Whether that's because it's a shared library or simply linked differently somehow, I don't know.  Even if it doesn't solve this problem though, I have to agree that at least having the option of building a shared lib would be very beneficial.  I'm sure a lot of people would appreciate it.  I know I would.   :wink:

[Denlecouscous]

Hello,

I'm currentl trying to integrate OIS in a wizard generated ogre application (Win XP, VC8 express),

and I'm encountering a link problem very similar to the one razor had.

Compile works fine, but linking ends up with the following error output.

Code: [Select]


InputManager.obj : error LNK2019: unresolved external symbol "public: static void __cdecl

OIS::InputManager::destroyInputSystem(void)" (?destroyInputSystem@InputManager@OIS@@SAXXZ) referenced

in function "public: virtual __thiscall InputManager::~InputManager(void)" (??1InputManager@@UAE@XZ)
InputManager.obj : error LNK2019: unresolved external symbol "public: static class OIS::InputManager

* __cdecl OIS::InputManager::createInputSystem...


Linking to the DLL (modifying oisconfig.h) I end up with even more link errors :
unresolved external symbol "__declspec(dllimport)...
- const OIS::KeyListener::`vftable'
- public: virtual __thiscall OIS::MouseListener::~MouseListener(void)
- public: virtual __thiscall OIS::KeyListener::~KeyListener(void)
- const OIS::MouseListener::`vftable'
and so on... createinputsystem and destroyinputsystem missing as well.

I have tried to change the include/references order without any success.
Commenting createinputsytem and destroy inputsystem (compiled against what I guess is static lib)

permits to successfully generate the solution without any error.

I must confess, I don't really know what I should try now...any idea is definitely welcome  

Thanks for your help.

[pjcast]

Did you build OIS yourself?

[Denlecouscous]

Thanks for this quick reply  

I'm basically using the SDK. However I also tried to build it (with VC7 in fact), but it seems to me it didn't change a thing.  :?
Do you think I need to compile it with VC8 express (in this case I would need dxsdk I guess) ?

[pjcast]

You should be able to get away with using the prebuilt vc8 binaries in the sdk. Make sure you are using the correct libs for your compiler.

[Denlecouscous]

I have triple checked, I'm linking to the vc8 libs   . Too bad it is not so easy   . Thanks for helping

[pjcast]

Ok, I suggest you forego using the SDK, and instead download the source yourself. Verify you can get the Console demo working, then use those generated libs in your project.