Menu
▾
▴
1 Attachments
#274 mingw32: can't (cross-)compile static library
Compiling and using a dll works fine. But I can't build and link a proper static library. With the current export flags from the Makefile the created static library seems to contain dll objetct files and linking against that library results in error messages about undefined _imp__* references.
Appearently it's not that difficult to build a working static library with MingW32.
Just apply the attached patch and make sure you build with -DDJVU_STATIC
See https://sourceforge.net/p/djvu/djvulibre-git/ci/2a931533402058c8671b7785ceeb1f943aee5521/ .
The usage is slightly different. The header files won’t redefine DDJVUAPI or MINILISPAPI if they’re already defined.
Therefore, instead of defining DJVU_STATIC, simply define DDJVUAPI and MINILISPAPI to empty strings: -DDDJVUAPI= -DMINILISPAPI=
Do not forget the trailing = otherwise it defines them to be “1”.
For the second fix, https://sourceforge.net/p/djvu/djvulibre-git/ci/c626c067f6a1e209a844e3cbaa7669aac5be3642/, the situation is more annoying. Basically, this black magic works only when compiling a DLL with MSVC. Without this code, you’ll have a small memory leak. This happens because windows does not give you a clean way to specify how a thread-local variable should be deallocated (unlike pthreads). The only way seems to be to intercept the THREAD_DETACH invocation of the DLL entry code, and the MSVC toolchain provides you a way to do this because the default DLL entry code will scan specific section names for function pointers to call. This is not well documented, but I found that in the winpthreads code...
From: Marshall darealshinji@users.sf.net
Reply-To: "[djvu:bugs]" 274@bugs.djvu.p.re.sf.net
Date: Friday, June 30, 2017 at 9:00 PM
To: "[djvu:bugs]" 274@bugs.djvu.p.re.sf.net
Subject: [djvu:bugs] #274 mingw32: can't (cross-)compile static library
Appearently it's not that difficult to build a working static library with MingW32.
Just apply the attached patch and make sure you build with -DDJVU_STATIC
Attachments:
djvulibre-static.patch (884 Bytes; text/x-patch)
[bugs:#274] mingw32: can't (cross-)compile static library
Status: open
Group: djvulibre
Labels: mingw32
Created: Tue Jun 14, 2016 11:26 AM UTC by Marshall
Last Updated: Tue Jun 14, 2016 11:26 AM UTC
Owner: nobody
Attachments:
build.log (78.7 kB; text/x-log)
Compiling and using a dll works fine. But I can't build and link a proper static library. With the current export flags from the Makefile the created static library seems to contain dll objetct files and linking against that library results in error messages about undefined _imp__* references.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/djvu/bugs/274/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
See https://sourceforge.net/p/djvu/djvulibre-git/ci/2a931533402058c8671b7785ceeb1f943aee5521/ .
The usage is slightly different. The header files won’t redefine DDJVUAPI or MINILISPAPI if they’re already defined.
Therefore, instead of defining DJVU_STATIC, simply define DDJVUAPI and MINILISPAPI to empty strings: -DDDJVUAPI= -DMINILISPAPI=
Do not forget the trailing = otherwise it defines them to be “1”.
For the second fix, https://sourceforge.net/p/djvu/djvulibre-git/ci/c626c067f6a1e209a844e3cbaa7669aac5be3642/, the situation is more annoying. Basically, this black magic works only when compiling a DLL with MSVC. Without this code, you’ll have a small memory leak. This happens because windows does not give you a clean way to specify how a thread-local variable should be deallocated (unlike pthreads). The only way seems to be to intercept the THREAD_DETACH invocation of the DLL entry code, and the MSVC toolchain provides you a way to do this because the default DLL entry code will scan specific section names for function pointers to call. This is not well documented, but I found that in the winpthreads code...