[BUG] Math component (commit b3fdf2087d0d)

[Transporter]

The commit b3fdf2087d0d produces a lot of C2491 errors in Visual Studio 2010 and 2012.

error C2491: XXXXX : definition of dllimport static data member not allowed

There are two ways how to fix it:

1. Remove all _OgreExport from all source files
2. Set OGRE_STATIC_LIB to force building a static lib

http://www.ogre3d.org/mantis/view.php?id=577

[Wolfmanfx]

Static lib wont work - every dll will contain than its own copy of the math library.
I will look into it

[Wolfmanfx]

Btw plz only use mantis the dev forum is either a bug/feature tracker. If everybody does it this sub-forum is polluted with that.

[masterfalcon]

Sorry about that. I don't have Visual Studio and didn't see any of those warnings from GCC and Clang. Since Math has to be static, perhaps we just need to remove _OgreExport from its classes?

[Transporter]

Btw plz only use mantis the dev forum is either a bug/feature tracker. If everybody does it this sub-forum is polluted with that.

I always write posts because I do not have the impression that mantis is processed. Additional here is a better place to discuss patches. If you like to reduce pollution you can create a subform Bugs.

Sorry about that. I don't have Visual Studio and didn't see any of those warnings from GCC and Clang. Since Math has to be static, perhaps we just need to remove _OgreExport from its classes?

You can do this, if there are no header used which require _OgreExport.

[Wolfmanfx]

Yep mantis is processed - but not on a daily base.

[Wolfmanfx]

Ok i checked it now and the situation is not that good.

1. When we build the math lib as static as it declared in the cmake file than every dll which make use of the math stuff has it own copy inside its so/dll/dynlib of course the linker will strip out code which is not used inside the dll - but it will increase the overall size of ogre when used with all the plugins.
The errors on windows happend because the you have a static lib which try to use dllimport on its own structures - wont work.
On gcc/clang you do not get this error because the defines their are empty.

2. When i try to make it a full blown dll/so so its reusable i fail because there are deps to ogre here the linker errors

Code: Select all

1>OgreVector4.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z) referenced in function "public: __thiscall Ogre::AxisAlignedBox::~AxisAlignedBox(void)" (??1AxisAlignedBox@Ogre@@QAE@XZ)
1>OgreSimpleSpline.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgreTangentSpaceCalc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgreVector2.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgreVector3.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgrePlane.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgrePolygon.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgreQuaternion.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgreRotationSpline.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgreNumerics.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgreOptimisedUtil.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" (__imp_?deallocateBytes@NedPoolingPolicy@Ogre@@SAXPAX@Z)
1>OgreOptimisedUtilGeneral.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl Ogre::NedPoolingPolicy::deallocateBytes(void *)" 
....
....
....
1>D:\OGRE\Build\bin\Debug\OgreMath_d.dll : fatal error LNK1120: 145 unresolved externals

One reason i did not tackle this ever and i think no other tackled this is that there is zero benefit it separation of the math component.
As you see when we do it the first we increase the binary size (when we do not a static ogre build) the second version is much more worse performance wise - no in lining of math which is used inside ogre.

[Transporter]

I agree! I thinks it could stay as part of OgreMain, because this is always linked if you build something with ogre. OgreMath would be always linked, too. Because you need the geometric stuff (vector etc.) to setup lights, meshs and whatever in the 3D world.

My patch needs to be updated. It is only working for a few projects not for all. OgreOverlay is not working. Removing the __declspec(dllimport) stuff (in a pure static lib) is also not working, because you need it in the DLL interface of several OgrMain functions.

[masterfalcon]

My mistake. But it was good to see some good analysis. I hadn't thought about the inlining of math functions so I apologize. At least now we can put this to rest. Although it would be nice to have the math separated for organization, the negative performance impact isn't worth it.

[Wolfmanfx]

We could start to use filters the work with xcode/vs with the latest cmake the fixed for xcode.

[Transporter]

We could start to use filters the work with xcode/vs with the latest cmake the fixed for xcode.

What are "filters" for xcode/vs?

Although it would be nice to have the math separated for organization, the negative performance impact isn't worth it.

What about a sub namespace for math? It's also possible to put the files in seperat foldes below OgreMain/src. That could simplify the organization. With this it's also possible to create tests for the math stuff without loading the whole ogre system.

Edit: The terrain bug was solved too by changeset 7251a2020e91.

[CABAListic]

The motivation for separating the math part is external: Basically, some people would like to be able to (re)use the Ogre math code without actually using the full Ogre library. Although I understand that desire, the problems outlined in this thread are the reason why I always cautioned that this is not nearly as trivial to do as some people believed.

One could perhaps reorganise the math code in such a way that the code could be built on its own, i.e. doesn't depend on other Ogre files. Ogre would still include it directly in OgreMain, but it could then also be built as a standalone library if someone had use for it. But failing that we should probably revert the split for now.

[dark_sylinc]

I agree, I never thought this would be a good option.

I do see the need for having an application to quickly debug what happens with the Math stuff (mostly to try out new math I write and it's not working for some reason. Loading all resources multiple times isn't efficient).

But the way to tackle this would be leaving a default blank application template (not part of SampleBrowser) that would link & load the minimum necessary to get to the math part and start debugging.
And if someone wants to go beyond that and use the Math part for their own needs, he can do it himself.

And CONGRATULATIONS! I'm pissed because the weekend I was going to upload an enhancement to Instancing Manager (per-entity arbitrary parameters) now I can't because it doesn't compile.
I dunno when I will have the time again to dedicate to this.

[masterfalcon]

Very sorry about that. But it has been reverted already.

I just figured that it would be a worthwhile experiment to get some feedback since it had been discussed before. But in the future we can just point anyone who suggests it to this thread.

Again, I'm very sorry for any inconvenience this has caused.

[dark_sylinc]

Thank you!! Already checked in the changes

[Transporter]

And CONGRATULATIONS! I'm pissed because the weekend I was going to upload an enhancement to Instancing Manager (per-entity arbitrary parameters) now I can't because it doesn't compile.

That sounds familiar to me

@masterfalcon
Don't worry about the discomfort of your try. It has been fixed very quickly. 1.9.0 is also an development branch where you can have errors and not a stable one. So there is no reason for compiling people to complain about an unstable state. Btw, it is an interesting topic to exclude and optimize the math parts.

[Kojack]

It would be cool if the math code was easy to integrate into other projects directly with minimal ogre dependencies, as just source files. No libs.
At the moment every math related source file pulls in a heap of dependencies including camera, archive, datastream, filesystem, movableobject, node, resource, serialiser, string, simplerenderable, and more.
At the very least we could make some replacement OgrePrerequisites.h and OgreStableHeaders.h for people that don't want to have cameras and stuff included just to use the math classes.

(I just did a compile of just ogrequaternion.cpp, it loads 2043 headers including over 500 from boost)

[Klaim]

I agree with Kojack.
My main concern with the maths part is that I have this kind of use case:

- one dll only is linking with Ogre (because it does all the graphic stuffs) - client side
- another dll does the (abstract) game specific stuffs - I don't have any physics (think about games like chess or starcraft), so no other system provide maths so far
- that game lib still need to manipulate 3D vectors and quaternions, not much, but enough so that Ogre code is perfect for that.
- at some point, the game lib send data containing maths some elements, sometime manipulations. it's easier to apply them to graphic parts when they are made out of the same library.

In this setup I have basically few solutions:
1. add another library just for game maths. I've used CML but I'm far from being happy with it so far.
2. setup my own basic math elements, taken from Ogre for example.
3. reuse Ogre in some way.

Ogre already provide all the manipulations I want and in a great interface so it's always tempting to just use Ogre.
3 is impossible without linking with Ogre, but I want the game lib to not, because it's server-side only .
1 is the most recommended around here but I'm not really satisfied (two interfaces for the same things, having to convert types between each side, etc).
I tried 2 but the problem is maintenance when it's updated in Ogre. Most of the time it's not really impacting me, but some fixes are.
It's a maintenance problem on my side because to make the code work outside of Ogre there is tons of modifications to do.

Now, as it's apparently difficult to do better, as Kojack said, finding a way to make the Ogre maths parts easily extractible would be far enough. If I can update Ogre, extract the lib and put it somewhere in my code without modification, I'm happy.


By the way, reading this thread and in particular point 2 of Wolfmanfx, I was thinking:
- make Ogre maths components header-only (I think Cabalistic discussed the possibility at some point?)
- making ogre maths classes parameterized by allocator (or something similar, just to avoid the link problem pointed)
- providing default math typedefs used inside Ogre.

Would it help? I assume I might miss an obvious problem with that... It should allow inlining at least.
If you think it might help I can try a patch this evening after work.

[PhilipLB]

Would it be possible to offer another cmake-File with which you could generate a pure OgreMath-project?

[IronNerd]

There is some new discussion about this in viewtopic.php?f=4&t=70522&start=135