Version: #define PVRTLSTRINGVERSION “5.1.0”
Compiler: Visual Studio 2015
OS: Windows 7
Platforms: Release + Debug, x86 + x64.
Now that PVRTexLib.dll is being imported, my engine no longer closes. All of the windows close, but a single thread remains active in the debugger:
This remains the case regardless of Debug/Release builds or x86/x64 builds. My engine waits inside common_exit() for the thread to do something and it never finishes.
This happens even if no functions are called inside the DLL. Simply loading the DLL causes this to happen later during shut-down.
#1: Is it possible to not use the DLL at all? I would strongly rather use a static link only to PVRTexLib.lib, but when I tried it still requested that the DLL be present. If I could link only to PVRTexLib.lib, it would solve this problem. #2: Otherwise I need to know how to solve this problem.
On our developer portal we have the latest release of PVRTexTool, this comes with a static library PVRTexLib.lib: Downloads - Imagination Developers
Let us know if that helps resolve the problem.
Hello Lawrence.
That is the static library I already have (unless it has been updated within the past few hours). Linking to it (and not the DLL) gives:
This is the case even if PVRTEXLIB_IMPORT is not defined. Dropping the DLL into the folder solves the issue but then I have the above issue with my engine no longer being able to close.
The instructions do not specify that using only the static library is possible and so do not come with any information on how to perform a static link, instead suggesting that only using the DLL is possible on Windows.
When the DLL is loaded, it starts 8 idle threads, one for each processor. One of these remains open when trying to shut down and unload the DLL. ::FreeLibrary() gives the same hanging situation.
I am pretty sure the static library itself links to the DLL. There is no way to link to the static library without it requesting the DLL on start-up.
PVRTEXLIB_IMPORT is not defined.
Linking to the DLL is not an option as it always results in shut-down hang, and linking to the static library is not an option because it forces linking to the DLL.
Fixing this will require a new build of the .LIB and the .DLL, which makes me wonder how I can possibly be the only person with this issue.
I need to release my tools. Will a fixed build be available soon?
I have been speaking with the tools team, the following is true:
The static lib is not really a static lib, but just an import library that tells the runtime linker which dll to load. and that PVRTexLib creates a thread pool with one thread for each CPU core.
However, we have never come across an issue where the threads block de-init before. We took a look at this callstack you attached, and the function signatures appear to match this project on github: https://github.com/Chuyu-Team/VC-LTL
This project is an opensource C runtime which would introduce different handling of dll loading and deinit. Since we only test the windows libraries with Microsoft’s runtime, this might explain why you are the first to encounter this problem, and would actually suggest an error in the runtime not in PVRTexLib.
If you are using the standard microsoft runtime, then a minimal example will help us rule out possible causes. I have attached a bare bones CMake project to test against.PVRTextLib_Test.zip (3.2 MB)
Simply extract the zip file
Open the extracted directory in a terminal:
mkdir build
cd build
cmake ..
And that will generate a Visual studios project, which just loads TexLib and transcodes an image, then exits. Hopefully this will help us pinpoint any issues. You will have to have Cmake ver 3.6+ in your path, or you can use the Cmake gui instead.
We’ve managed to reproduce this issue, using that runtime library. We have a fix that we could supply to you as an engineering drop if you send us a ticket over here: https://pvrsupport.imgtec.com/
We also have a release coming up soon that will contain this fix.
I am not using that library, but I have MSVCRT added to my “Ignore Specific Default Libraries” setting, which must generate code very similar to what that library generates.
I have filed a ticket and look forward to making progress with an engineering drop. I build for both x86_32 and x86_64.
The DLL almost worked, but while it successfully shuts down if loaded and not used, it still fails shut-down if it was used for PVRTC conversion. For example to GL_COMPRESSED_RGBA_PVRTC_4BPPV2_IMG from RGBA F32.
