Another variant on the eternal newbie linker errors

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
Kidinnu
Posts: 10
Joined: Fri Jun 02, 2006 6:54 pm
Location: North Carolina, USA

Another variant on the eternal newbie linker errors

Post by Kidinnu »

So, I set up a project from scratch, copied and pasted tutorial 12, and everything built & ran just fine.

I decided I wanted to change the camera behavior. Rather than hacking Irrlicht internals, I created my own class (txCCameraFPSSceneNode) and added it to the project. After much cursing at the really bad error messages of MSVC 6.0 (8.0 is installing as I type), my new class compiles. However, when I go to link the project, I get the eternally-recurring:

txCCameraFPSSceneNode.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall irr::scene::CCameraSceneNode::isInputReceiverEnabled(void)" (?isInputReceiverEnabled@CCameraSceneNode@scene@irr@@UAE_NXZ)
{repeat 25 times for various irr:: bits and pieces}

When I'm just compiling my tutorial12 implementation without the new class, it links fine, so I'm pretty sure that I've got the library path right, and copied the DLL into the correct directory. Why is it that I'm having this problem when I try to link two object files?

Update:

The same kind of error happens with 8.0. (And it still depends on including my new file; if I don't include the new file in the project, everything's fine.)
Turning on verbose linking progress messages doesn't give me any clues; MSVC doesn't report finding any functions to link with in the .lib.
nm -a doesn't report anything but (a few of) the os-specific symbols in Irrlicht.lib; I'd think the rest would be coming from the dll.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

But CCameraSceneNode is from the original Irrlicht scene node. So you seem to have messed with the Irrlicht source (or made too much copy&paste from the original code).
Kidinnu
Posts: 10
Joined: Fri Jun 02, 2006 6:54 pm
Location: North Carolina, USA

Post by Kidinnu »

hybrid wrote:But CCameraSceneNode is from the original Irrlicht scene node. So you seem to have messed with the Irrlicht source (or made too much copy&paste from the original code).
The error message occurs while trying to link txCCameraSceneNode, which is the new class I created. It inherits from CCameraSceneNode; the linker hangs up when it's trying to link in the virtual functions from the parent class (as well as some functions being called on other classes).
Baal Cadar
Posts: 377
Joined: Fri Oct 28, 2005 10:28 am
Contact:

Post by Baal Cadar »

Kidinnu, your linker can't access CCameraSceneNode, because it isn't exported from Irrlicht. In order for you to use such classes, they need to be declared __declspec(dllexport) during library creation. Not the case for any class in Irrlicht. Code reuse is made a bit difficult this way. What you can do is, to change the put IRRLICHT_API into the class definition. This gets correctly expaned to either __declspec(dllexport) or __declspec(dllimport). Note, that you have to recompile Irrlicht afterwards. I haven't tested it, it should work, but may require further changes.
No offense :)
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Isn't there an 'expor all symbols' switch? At least mingw should have one. Or later on extract them from the dll file to build a new .lib file. I don't recall these things ver well anymore, but I think you can come across these limitations. However, gcc 4 also adds some of these things so Linux users will have to face such things in the future as well...
Kidinnu
Posts: 10
Joined: Fri Jun 02, 2006 6:54 pm
Location: North Carolina, USA

Post by Kidinnu »

OK, so I can either compile my own new code into the library, change the library interface so the classes are exposed, or just inherit from the ICameraSceneNode interface and reimplement all the behavior myself?

None of those is a very maintainable route to extension, since either will require explicit patching when the library updates. Double yuck.

Thanks for the help. I'll dig into it Monday.
Post Reply