- July 9, 2014 at 3:49 am #31762
PVRTexTool lib includes dir:
It turns out that symbols in PVRTTexture.obj(GraphicsSDKPVRTexToolLibraryIncludePVRTTexture.cpp) are redefined in PVRTexLib.lib which contains symbols in GraphicsSDKPVRTexToolLibraryIncludePVRTTexture.h.
error LNK2005: “public: bool __thiscall MetaDataBlock::ReadFromPtr(unsigned char const * *)” (?ReadFromPtr@MetaDataBlock@@QAE_NPAPBE@Z) already defined in PVRTexLib.lib(PVRTTexture.obj)July 11, 2014 at 10:07 am #38886
Is anyone here?
AFAIS, it is an design error to put symbols in global namespace when designing a static library.July 11, 2014 at 10:20 am #38887
I’ve seen the post and have asked the PVRTexTool lead engineer to follow up with you. He’s out of the office today, so may not be able to look into this until next week.
JoeJuly 14, 2014 at 9:27 am #38888
You should be able to use the two together, but you probably have to remove PVRTTexture from the Tools project and rebuild it assuming that it’s there in PVRTexLib. I’d have had to basically write a separate version of the file to get it out of the global namespace, or wrap the whole thing with some preprocessor code, amongst other code changes. In all honesty though – it’s just something I’ve never considered (this was all originally a bunch of C libraries so it didn’t necessarily make sense to namespace things in the past). Alternatively, you can work around it by linking with the dynamic version of PVRTexLib.
This is something that should be fixed in the new framework when it comes out. Until then I’m not sure what to do -we’ll probably end up wrapping it in preprocessor code for the PVRTexLib build or moving some code around to avoid the clash, but this will require a number of code changes. I’ve filed a bug against it here. Check this item for updates – if you up-rank it, it should notify you whenever there’s an update.