Hi Robert, Thank you for your second answer!
But I guess a configuration at runtime won't work. The sheer activation of the SetThreadDescription call in the log4cxx source code (after cmake set the LOG4CXX_HAS_SETTHREADDESCRIPTION preprocessor variable) causes that the program does not start up at all on Windows Server 2016. SetThreadDescription is never called in my test program (because the program does not start at all; that is far before any log4cxx configuration can be read). But your first answer was sufficient for me: we have to compile in a way that finally the SetThreadDescription call is not in the object files. Thank you again and best regards, Michael ----Original Message----- From: Robert Middleton <osfan6...@gmail.com> Sent: Donnerstag, 1. Dezember 2022 14:26 To: Log4CXX User <log4cxx-user@logging.apache.org> Subject: Re: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found [You don't often get email from osfan6...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogging.apache.org%2Flog4cxx%2Flatest_stable%2Fthreading.html%23threading-notes&data=05%7C01%7CMichael.Schumacher%40inform-software.com%7C53a5335ebb6f46ff709108dad39fae45%7C36c737afe6e84ba685f855440ef5fd6c%7C0%7C0%7C638054980019503898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=91tk77DKRQIo8DV1W5doA2MNo8BFk2DKD1KCQNCfUHw%3D&reserved=0 -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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fle > > arn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fapi%2Fprocessthreadsap > > i%2Fnf-processthreadsapi-setthreaddescription&data=05%7C01%7CMic > > hael.Schumacher%40inform-software.com%7C53a5335ebb6f46ff709108dad39f > > ae45%7C36c737afe6e84ba685f855440ef5fd6c%7C0%7C0%7C638054980019503898 > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WsKkW1AadpuB1Jjsdq > > ZCzoTHktN84%2BFuJ2vG0tmga7o%3D&reserved=0 > > > > 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 > > > > > > > >
