Describe the problem
In my Linux Suse, which has the older glibc installed (older than 2.12), to support backward compatibility for others' software. I tried installing wxWidgets using :
CFLAGS="-std=c99 -fPIC" CXXFLAGS="-fPIC"
make && make install
The introduction of the function: pthread_setname_np with 3.1.7 of wxWidgets is breaking up my build. Can this section of code be made to support backward compatibility?
Please attach the full build log, but feel free to quote the relevant parts of
it here.
Error: "pthread_setname_np" not declared in the scope in ./src/unix/threadpsx.cpp
Platform and version information
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Does this patch (heavily inspired by this) solve the issue for you:
diff --git a/src/unix/threadpsx.cpp b/src/unix/threadpsx.cpp
index 4876ac2..d4f0d63 100644
--- a/src/unix/threadpsx.cpp
+++ b/src/unix/threadpsx.cpp
@@ -64,6 +64,7 @@
// we use wxFFile under Linux in GetCPUCount()
#ifdef __LINUX__
#include "wx/ffile.h"
+ #include <sys/prctl.h>
#endif
// We don't provide wxAtomicLong and it doesn't seem really useful to add it
@@ -1696,12 +1697,19 @@ bool wxThread::SetNameForCurrent(const wxString &name)
#if defined(__DARWIN__)
pthread_setname_np(name.utf8_str());
return true;
-#elif defined(__LINUX__)
+#elif defined(__LINUX__) && defined(__GLIBC_PREREQ) && __GLIBC_PREREQ(2,12)
// Linux doesn't allow names longer than 15 bytes.
char truncatedName[16] = { 0 };
strncpy(truncatedName, name.utf8_str(), 15);
return pthread_setname_np(pthread_self(), truncatedName) == 0;
+#elif defined(__LINUX__) && defined(PR_SET_NAME) // available since Linux 2.6.9
+ // Linux doesn't allow names longer than 15 bytes.
+ char truncatedName[16] = { 0 };
+ strncpy(truncatedName, name.utf8_str(), 15);
+
+ return prctl(PR_SET_NAME,
+ (unsigned long)(void*)truncatedName, 0, 0, 0);
#else
wxUnusedVar(name);
wxLogDebug("No implementation for wxThread::SetName() on this OS.");
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Thanks, I didn't know about __GLIBC_PREREQ, but now that I do, I don't know if we should use it in the other places where we check for __GLIBC__ currently or, on the contrary, should also avoid using it here for consistency.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I've made #22564 with a slightly modified version of the patch above, please let me know if you see any problems with it, TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Closed #22559 as completed via 5333897.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()