Note that you may also just be able to configure this at runtime. Assuming that you are using a configuration file to configure Log4cxx, you can probably set the ThreadConfigurationType to not name threads, meaning the code is never called. See this documentation for more details: https://logging.apache.org/log4cxx/latest_stable/threading.html#threading-notes
-Robert Middleton On Thu, Dec 1, 2022 at 8:20 AM Robert Middleton <osfan6...@gmail.com> wrote: > > Hi Michael, > > The best thing for me to recommend is to simply comment out the checks > for SetThreadDescription and GetThreadDescription as you have done. > This is really designed to be an optional feature, such that you can > print out the name of the thread rather than just its ID in hex. At > least under Linux and GDB this also means that the thread name will > show up in the debugger; I assume the same is true on Windows. > > -Robert Middleton > > On Thu, Dec 1, 2022 at 6:55 AM Michael Schumacher > <michael.schumac...@inform-software.com> wrote: > > > > Hi, > > > > > > > > we have an issue with log4cxx.dll, version 0.13.0; here is what we found > > out so far: > > > > We built log4cxx.dll on a Windows Server 2019 with cmake (from the > > downloaded apache-log4cxx-0.13.0.zip). > > > > In apache-log4cxx-0.13.0\src\main\include\CMakeLists.txt the four lines > > below activate the SetThreadDescription / GetThreadDescription calls > > (because in the Windows SDK on that machine processthreadapi.h contains > > Set/GetThreadDescription): > > if(WIN32) > > CHECK_SYMBOL_EXISTS(SetThreadDescription > > "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION) > > CHECK_SYMBOL_EXISTS(GetThreadDescription > > "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION) > > endif(WIN32) > > And here is the call in threadutility.cpp: > > ... > > #elif LOG4CXX_HAS_SETTHREADDESCRIPTION > > HRESULT hr = SetThreadDescription(static_cast<HANDLE>(nativeHandle), > > threadName.c_str()); > > ... > > That means now log4cxx.dll needs an entry point for SetThreadDescription as > > soon as a client program that linked log4cxx.lib is started > > > > I made a small console program (named logConsole) with only one call to > > log4cxx in main() (after the “Hello World!” std::cout output): > > log4cxx::helpers::LogLog::setQuietMode(true); > > On a Windows Server 2019 or on Windows 10, the program starts and I see > > ‘Hello World!’ > > Now the issue: on a Windows Server 2016 (version 1607), the program does > > not start up at all. > > > > In the event viewer’s system log, the following “Application popup” message > > appears: > > Application popup: logConsole.exe - Entry Point Not Found : The procedure > > entry point SetThreadDescription could not be located in the dynamic link > > library C:\Users\xyz\Documents\log4cxx.dll. > > > > > > > > That means any program that uses this log4cxx.dll compiled on Windows 10 > > won’t even start up on Windows Server 2016. > > > > > > > > Here is what Microsoft says in: > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription > > > > Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: > > SetThreadDescription is only available by Run Time Dynamic Linking in > > KernelBase.dll. > > > > > > > > As far as I can see there is no Run Time Dynamic Linking (via LoadLibrary) > > in the source code around the SetThreadDescription and GetThreadDescription > > calls. > > > > > > > > Has anyone an idea what to do to avoid the problem on old machines? > > > > > > > > My first guess is to delete these lines (but then the new calls are never > > made): > > > > if(WIN32) > > CHECK_SYMBOL_EXISTS(SetThreadDescription > > "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION) > > CHECK_SYMBOL_EXISTS(GetThreadDescription > > "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION) > > endif(WIN32) > > > > > > > > Thank you in advance for any responses! > > > > > > > > Best Regards, > > > > Michael > > > > > > > >
