Hi out there !
I’m trying to decompress pvr textures on a windows program I’m developing using codeblocks (mingw). I added PVRTexLib.lib and the DLL, and my code has:
#define _WINDLL_IMPORT
#include <PVRTexLib.h>
However I get 2 errors I have no idea what they mean:
<code>
In file included from libs/PVRTexLib/PVRTexLib.h:21,
from C:Documents and SettingsRicardoEscritorioiPhonedonkeysourceCTextureManager.cpp:14:
libs/PVRTexLib/PVRTexLibGlobals.h:34:21: #if with no expression
In file included from libs/PVRTexLib/CPVRTextureData.h:19,
from libs/PVRTexLib/PVRTexLib.h:23,
from C:Documents and SettingsRicardoEscritorioiPhonedonkeysourceCTextureManager.cpp:14:
libs/PVRTexLib/PVRTGlobal.h:27:21: crtdbg.h: No such file or directory
</code>
Is mingw or gcc compatible with this library?
Am I missing something?
Should I try out PVRTexLib.a (which is for linux)?
Thanks a lot for suggestions and ideas
Ricardo.
The header crtdbg.h is part of the Visual Studio compiler suite and it’s used in all our windows builds for convenience and we officially only support this compiler for Windows. However, I don’t believe PVRTexLib uses any of the functionality so it should be possible to use the dll with other environments.
If you examine the file PVRTGlobals.h then you should be able to find the #include that’s causing the problem. If you remove this (and possibly some other stuff from this file) then I think the library should work ok after that. Please ask if you have any trouble.
I will look into fixing the problem for our next release (it’s now issue BRN27030).
Thanks a lot for reply!
However, now I get new and exciting erros, and I don't know if my compiler is responsible:
I changed this:
#ifndef PVR_DLL
#ifdef _WINDLL_EXPORT
#define PVR_DLL __declspec(dllexport)
#elif _WINDLL_IMPORT
#define PVR_DLL __declspec(dllimport)
#else
#define PVR_DLL
#endif
#endif
For just this:
#define PVR_DLL __declspec(dllimport)
My program defines _WINDLL_EXPORT, and I removed that things about vs debugger, but when I try to use the library, lets say something easy like:
pvrtexlib::CPVRTexture sDecompressedTexture;
I get some linker errors (despite the fact I added PVRTexLib.lib to my linker settings and copied the DLL to my EXE or bin folder)
I get this:
<code>
ibs/PVRTexLib/CPVRTextureData.h:30: warning: type attributes are honored only at type definition
In file included from libs/PVRTexLib/PVRTexLib.h:24,
from C:Documents and SettingsRicardoEscritorioiPhonedonkeysourceCTextureManager.cpp:14:
libs/PVRTexLib/CPVRTextureHeader.h:30: warning: type attributes are honored only at type definition
Linking console executable: binSimulator_debug.exe
objDebugsourceCTextureManager.o: In function `_ZN15CTextureManager10LoadPVR_PCEPcPbPjS2_S1_':
C:/Documents and Settings/Ricardo/Escritorio/iPhone/donkey/source/CTextureManager.cpp:138: undefined reference to `__imp___ZN9pvrtexlib11CPVRTextureC1Ev'
objDebugsourceCTextureManager.o: In function `_ZN4CApp13GetLogManagerEv':
C:/Documents and Settings/Ricardo/Escritorio/iPhone/donkey/source/CTextureManager.cpp:(.text$_ZN9pvrtexlib11CPVRTextureD1Ev[pvrtexlib::CPVRTexture::~CPVRTexture()]+0x10): undefined reference to `__imp___ZN9pvrtexlib15CPVRTextureDataD1Ev'
collect2: ld returned 1 exit status
</code>
Did anyone use this library sucesfully with mingw or codeblocks? Or am I doing anything wrong?
Thanks lot for your time and help, I appreciate it a lot.
Ricardo.
riruilo2009-04-08 19:47:33
After removing the #ifdefs I’m surprised you aren’t getting multiple definition errors in your compile - I’m pretty certain that change isn’t necessary.
As I say, we don’t officially support other compilers than the VS one on Windows so linking to PVRTexLib has never been tested here with other environments. Sadly, no-one here seems to have experience linking to a VS dll from mingw either.
However, what appears to be going wrong is to do with VS’s decoration of the exported symbols. PVRTexLib is a C++ library - if it were C this would be alot easier - sadly I wrote the library before we decided it might be useful for developers and I really don’t want to rewrite the interface all over again… The mingw compiler doesn’t understand the mangling the VS does and so the linking doesn’t work.
Ideas:
- Are there any Microsoft compatibility options in the compiler you’re using?
- It’s possible that you might be able to load the DLL at runtime. I’m not very hopeful of that working tbh as the symbols are still mangled.
- Use Visual Studio (probably not your favourite option).
What exactly are you using PVRTexLib for? It’s possible that you can get the functionality you need in a different way - the PVRTC library, for instance, is entirely C and should be much easier to link to and there may be functions in our PVRTools or Shell code that could help you.
Thanks a lot for your help
I’m doing a game for the iPhone which also executes on Windows (win version is for developement and debug purposes) . I’m using basically SDL, C++ (I avoid objective C) and my own little opengl engine.
All my code executes perfectly on both systems, but obviously the way I load PVR must be different. Loading PVR files on the iPhone is very easy, and I have it already working.
So, depending on a define parameter, I compile the windows or iphone version.
I have LoadPVR_iPhone and LoadPVR_PC methods.
LoadPVR_iPhone reads the file, header and data and upload it using glCompressedTexImage2D. Very easy.
But LoadPVR_PC should convert or decompress the file using your library to a raw format and upload it using glTexImage2D.
That is the reason I must use your library. By the way, Why did you do a C++ library instead of a C library (it’s just about manipulating images, nothing extraordinary)?
On the other hand, I always prefer to use open source tools like CODEBLOCKS with MINGW, but if there is no way to use your library (which seems was not designed to be multiplatform or cross compilable, or whatever) on codeblock, I’m afraid I will have to change to visual studio
I changed those #ifdefs because it was an error over there. Try to compile it on codeblocks and you will see it.
Thanks a lot forr help
Never mind, I will try Visual Studio.
We encountered the same problem in our own code when running on PC. Eventually our solution was to integrate PVRTC support into the emulation library that we use, but for a long time we would simply decompress PVRTC textures on-the-fly before giving them to GL.
The code for this is still in the PVRTools at Tools/PVRTDecompress.h/cpp. This will allow you to decompress the PVRTC textures within your own code without needing to link into PVRTexLib.
PVRTexLib is the functional part of PVRTexTool - the public interface hides a lot of the functionality that PVRTexLib has in-house. Our utilities are written in C++ (as is all our SDK code) so I wrote a C++ library (things like exceptions, templates etc. are utilised pretty heavily in the library and PVRTexTool application and would have been a real pain with a purely C implementation IMO). This is actually the first request we’ve had for a non-Visual Studio compiler on Windows (and it’s not like the VS one isn’t available) so we haven’t supported other ones in the past. We may change this policy and if so I’ll post back here.
In the meantime, though I suggest using the PVRTools/PVRTDecompress functionality.
The code for this is still in the PVRTools at Tools/PVRTDecompress.h/cpp. This will allow you to decompress the PVRTC textures within your own code without needing to link into PVRTexLib.
PVRTexLib is the functional part of PVRTexTool - the public interface hides a lot of the functionality that PVRTexLib has in-house. Our utilities are written in C++ (as is all our SDK code) so I wrote a C++ library (things like exceptions, templates etc. are utilised pretty heavily in the library and PVRTexTool application and would have been a real pain with a purely C implementation IMO). This is actually the first request we've had for a non-Visual Studio compiler on Windows (and it's not like the VS one isn't available) so we haven't supported other ones in the past. We may change this policy and if so I'll post back here.
In the meantime, though I suggest using the PVRTools/PVRTDecompress functionality.
OK, thanks. I already have your library running on Visual Studio. I would have prefered running the lib on codeblocks, but, well, it does not matter.
Can anyone help? I am trying to compile a windows console application in VS 2005. I cannot for the life of me get the project to link against pvrtc.lib.
I am using OGLES-1.1_WINDOWS_PCEMULATION_2.04.24.0811UtilitiesPVRTClibWindows
I include the pvrtc.h
I add pvrtc.lib to my eternal dependencies.
then all I get when linking is:
LINK : warning LNK4098: defaultlib ‘MSVCRT’ conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib ‘LIBCMT’ conflicts with use of other libs; use /NODEFAULTLIB:library
TexPress.obj : error LNK2019: unresolved external symbol “int __cdecl pvrtc_size(int,int,int,int)” (?pvrtc_size@@YAHHHHH@Z) referenced in function “int __cdecl pvrpacker(char const *,char const *)” (?pvrpacker@@YAHPBD0@Z)
I tried doing the NODEFAULTLIB thing and that makes every printf and fopen unresolvable.
Isn’t this supposed to work with visual studio?
What am I missing?
This looks like a problem with the runtime library not matching between your project and the library. Try ensuring that the setting C/C++/Code Generation/Runtime Library is set to /MT (multithreaded).
It is possible that PVRTexLib sources will be available for free? I think that in this case compatibility problems will disappear
Hi gamedev,
This issue was fixed a long time ago, as this topic is from 2009. It was a problem with library linkage which has since been solved. At the moment there are no plans to open source any of our utility code.
Thanks,
Tobias
But how it was fixed? It can be used in windows under mingw? No, thats why I ask it
Thanks
gamedev2012-09-14 21:45:12
Hi gamedev,
The library was changed to link statically which generally means that there should be fewer problems with linking different versions. However there are still issues because of Visual Studio’s linking rules. We are looking into ways to lessen this (such as removing any of the code deemed as specific to the VS version). Whether this will be possible, and whether it will still maintain the dependency on visual studio is unclear at this point. There are no current plans to support any other platforms specifically though I’m afraid.
Thanks,
Tobias
