[BUG] Math component (commit b3fdf2087d0d)

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 2

[BUG] Math component (commit b3fdf2087d0d)

Post by Transporter » Sat Oct 06, 2012 3:33 pm

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
Attachments
ogre-math.patch
Bugfix
(1.85 KiB) Downloaded 89 times
0 x

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Wolfmanfx » Sat Oct 06, 2012 3:48 pm

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

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Wolfmanfx » Sat Oct 06, 2012 3:49 pm

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.
0 x

User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by masterfalcon » Sat Oct 06, 2012 4:27 pm

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?
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 2

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Transporter » Sat Oct 06, 2012 4:34 pm

Wolfmanfx wrote: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.
masterfalcon wrote: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.
0 x

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Wolfmanfx » Sat Oct 06, 2012 4:44 pm

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

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Wolfmanfx » Sat Oct 06, 2012 9:30 pm

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.
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 2

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Transporter » Sat Oct 06, 2012 9:50 pm

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.
0 x

User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by masterfalcon » Sat Oct 06, 2012 9:54 pm

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.
0 x

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Wolfmanfx » Sat Oct 06, 2012 9:56 pm

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

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 2

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Transporter » Sat Oct 06, 2012 10:10 pm

Wolfmanfx wrote: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? :?
masterfalcon wrote: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.
0 x

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by CABAListic » Sat Oct 06, 2012 10:36 pm

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.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4151
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 273
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by dark_sylinc » Sat Oct 06, 2012 11:10 pm

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. :evil: :evil: :evil:
I dunno when I will have the time again to dedicate to this.
0 x

User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by masterfalcon » Sat Oct 06, 2012 11:25 pm

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.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4151
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 273
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by dark_sylinc » Sun Oct 07, 2012 12:08 am

Thank you!! Already checked in the changes :D
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 2

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Transporter » Sun Oct 07, 2012 12:49 am

dark_sylinc wrote: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. :evil: :evil: :evil:
That sounds familiar to me :D

@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.
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7152
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 19

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Kojack » Sun Oct 07, 2012 3:04 am

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)
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by Klaim » Mon Oct 08, 2012 9:31 am

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.
0 x

PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by PhilipLB » Mon Oct 08, 2012 9:43 am

Would it be possible to offer another cmake-File with which you could generate a pure OgreMath-project?
0 x
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.

IronNerd
Gnoblar
Posts: 8
Joined: Mon Apr 23, 2012 11:35 am

Re: [BUG] Math component (commit b3fdf2087d0d)

Post by IronNerd » Thu Nov 01, 2012 9:04 am

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

Post Reply