[Help] gcc11 compiles thread_local variable, BE start: version `GLIBC_2.18' not found
#7911
Conversation
xinyiZzz
force-pushed
the
thread_local_include
branch
from
1837c81 to
6a252d7
Compare
|
PTAL @amosbird , if you have time, thanks |
|
Is it for some future PRs with thread local? |
Yes, @xinyiZzz is developing memory tracking and management based on thread local. |
Cool. Will take a look. |
|
I did some investigation. It's not easy to mask this symbol, which is meant to be added to the libc++abi. It's also not safe to use the polyfill implementation from some libc++api directly. I'd suggest the following:
|
Thanks for the answer~ @amosbird My pr: #7198 |
You can redesign the implementation of your thread_local structs to have trivial destructor. The definition is in https://en.cppreference.com/w/cpp/language/destructor . |
I think I understand trivial destructor, thanks again, very helpful @amosbird |
The thread context saves some info about a working thread.
1. thread_id: Current thread id, Auto generated.
2. type: The type is a enum value indicating which type of task current thread is running.
For example: QUERY, LOAD, COMPACTION, ...
3. task id: A unique id to identify this task. maybe query id, load job id, etc.
Using gcc11 compiles thread_local variable on lower versions of GLIBC will report an error, see #7911
This is very difficult to solve, so kudu Class-scoped static thread local implementation was introduced.
Solve the above problem by Thread-scopedthread local + Class-scoped thread local.
See the comments for ThreadContextPtr for details.
…he#7234) The thread context saves some info about a working thread. 1. thread_id: Current thread id, Auto generated. 2. type: The type is a enum value indicating which type of task current thread is running. For example: QUERY, LOAD, COMPACTION, ... 3. task id: A unique id to identify this task. maybe query id, load job id, etc. Using gcc11 compiles thread_local variable on lower versions of GLIBC will report an error, see apache#7911 This is very difficult to solve, so kudu Class-scoped static thread local implementation was introduced. Solve the above problem by Thread-scopedthread local + Class-scoped thread local. See the comments for ThreadContextPtr for details.
The thread context saves some info about a working thread.
1. thread_id: Current thread id, Auto generated.
2. type: The type is a enum value indicating which type of task current thread is running.
For example: QUERY, LOAD, COMPACTION, ...
3. task id: A unique id to identify this task. maybe query id, load job id, etc.
Using gcc11 compiles thread_local variable on lower versions of GLIBC will report an error, see #7911
This is very difficult to solve, so kudu Class-scoped static thread local implementation was introduced.
Solve the above problem by Thread-scopedthread local + Class-scoped thread local.
See the comments for ThreadContextPtr for details.
…he#7234) The thread context saves some info about a working thread. 1. thread_id: Current thread id, Auto generated. 2. type: The type is a enum value indicating which type of task current thread is running. For example: QUERY, LOAD, COMPACTION, ... 3. task id: A unique id to identify this task. maybe query id, load job id, etc. Using gcc11 compiles thread_local variable on lower versions of GLIBC will report an error, see apache#7911 This is very difficult to solve, so kudu Class-scoped static thread local implementation was introduced. Solve the above problem by Thread-scopedthread local + Class-scoped thread local. See the comments for ThreadContextPtr for details.
3 participants
Problem Summary:
Error details in be.out:
nm looks at palo_be and finds that the method that depends on GLIBC_2.18 is
__cxa_thread_atexit_implI found that the
__cxa_thread_atexit_implmethod was introduced by glibc to support thread_local variableshttps://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables
It was no problem to compile through gcc10 before
So, how can I avoid this problem, ask for help.