Marshall

Is it better to use the MSCV code for MinGW? Or does it really make no difference? The primary use case for the static library is to build and link everything to a single exe binary using the same MinGW compiler/toolchain, so the chance that a different pthread library is used should be low. 08.11.2023 16:28:51 Leon Bottou leonb@users.sourceforge.net: warning "This only works with MSVC. Memory leak otherwise" Now I remember this horror. The handling of thread local storage under windows is a catastrophe....

Just to make sure, do you confirm that adding DJVUAPI on Monitor and GSafeFlags is enough to make --export-all-symbols useless when compiling libdjvu as a dll? This was at least the case during my tests, yes. But I will do some more tests. Update: this isn't needed anymore it seems. pthreads: What is the benefit of using MINGW's pthread emulation on Windows? Same thing again: it can make sense to give priority to pthread if detected, but will this work on all platforms? I've tested enabling pthreads...

Just to make sure, do you confirm that adding DJVUAPI on Monitor and GSafeFlags is enough to make --export-all-symbols useless when compiling libdjvu as a dll? This was at least the case during my tests, yes. But I will do some more tests. Update: this isn't needed anymore it seems. pthreads: What is the benefit of using MINGW's pthread emulation on Windows? Same thing again: it can make sense to give priority to pthread if detected, but will this work on all platforms? I've tested enabling pthreads...

Just to make sure, do you confirm that adding DJVUAPI on Monitor and GSafeFlags is enough to make --export-all-symbols useless when compiling libdjvu as a dll? This was at least the case during my tests, yes. But I will do some more tests. pthreads: What is the benefit of using MINGW's pthread emulation on Windows? Same thing again: it can make sense to give priority to pthread if detected, but will this work on all platforms? I've tested enabling pthreads because of a warning I got during compilation,...

You should also enable pthread checks for Windows because implementations are avaiable for MinGW compiler. And if pthread wasn't found then HAVE_PTHREAD won't be set. Regarding -fvisibility: you could add compiler flag checks to configure.ac for these and other flags.

You should also enable pthread checks for Windows because implementations are avaiable for MinGW compiler. And if pthread wasn't found then HAVE_PTHREAD won't be set.

The changes in JPEGDecoder are needed because the build will otherwise break for some people on MinGW32: https://github.com/mxe/mxe/issues/3012 Besides I really wonder what these strange redefines are even meant for. They're not needed for GCC Linux and MinGW so I guess they're some workaround for MSVC? -fvisibility is known by clang but I guess you can make it optional. The user can always add it to the build flags themself.

Here's a much better patch. It will use »__attribute__((visibility("default")))« if a GNU compiler is used which works well on MinGW and Linux targets.