error C2491: XXXXX : definition of dllimport static data member not allowed
There are two ways how to fix it:
- Remove all _OgreExport from all source files
- Set OGRE_STATIC_LIB to force building a static lib
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.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.
You can do this, if there are no header used which require _OgreExport.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?
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
What are "filters" for xcode/vs?Wolfmanfx wrote:We could start to use filters the work with xcode/vs with the latest cmake the fixed for xcode.
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.masterfalcon wrote:Although it would be nice to have the math separated for organization, the negative performance impact isn't worth it.
That sounds familiar to medark_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.