See the comment on needs_musl_ap_cached() for an explanation on this PR.
I'm not adding an automatic test now because async-profiler currently fails running on the image I used to test it, anyway. The glibc build requires libstdc++ (unlike the musl build) but the image has musl and glibc-compat but NO libstdc++. At the very least, we don't crash glibc-compat processes anymore :shrug: which is what happens before this PR. That's a start...
I'm not sure I plan to support a glibc build with static libstdc++ (for this case) because async-profiler might, in the near future, be libc agnostic, and then we have to restructure the code here anyway. My goal with this PR now is to avoid crashing glibc-compat processes.
I tested it against the image ngrinder/controller:3.5.5 which runs a glibc-compat Java app.
See related async-profiler ticket which explains further: https://github.com/async-profiler/async-profiler/pull/717
See the comment on
needs_musl_ap_cached()
for an explanation on this PR. I'm not adding an automatic test now because async-profiler currently fails running on the image I used to test it, anyway. The glibc build requires libstdc++ (unlike the musl build) but the image has musl and glibc-compat but NO libstdc++. At the very least, we don't crash glibc-compat processes anymore :shrug: which is what happens before this PR. That's a start...I'm not sure I plan to support a glibc build with static libstdc++ (for this case) because async-profiler might, in the near future, be libc agnostic, and then we have to restructure the code here anyway. My goal with this PR now is to avoid crashing glibc-compat processes.
I tested it against the image
ngrinder/controller:3.5.5
which runs a glibc-compat Java app.Related granulate-utils PR: https://github.com/Granulate/granulate-utils/pull/134