Two days ago, I did:
> 2024-07-17 Bruno Haible
>
> stack-trace: Use libasan as an alternative to libbacktrace.
> * m4/stack-trace.m4 (gl_STACK_TRACE_EARLY): As a second choice, use
> libasan.
It turns out that this does not work well:
1) When '-lasan' is added to LIBS, many
Paul Eggert wrote:
> If I understand things correctly a similar problem was also on FreeBSD
> with PIE and the bug wasn't fixed until November of last year:
>
> https://github.com/llvm/llvm-project/commit/7440e4ed85aa992718d4b5ccd1c97724bc3bdd2c
Btw, I don't know why they do this. For the purpos
Paul Eggert wrote:
> If I understand things correctly a similar problem was also on FreeBSD
> with PIE and the bug wasn't fixed until November of last year:
>
> https://github.com/llvm/llvm-project/commit/7440e4ed85aa992718d4b5ccd1c97724bc3bdd2c
This issue does not affect the Gnulib 'stack-trace
On 2024-07-18 04:21, Bruno Haible wrote:
on NetBSD 10.0, every program that links with libasan exits
without even reaching main(). It merely prints
"This sanitizer is not compatible with enabled ASLR"
to standard error and exits with status 0 (yes, 0 !!!).
If I understand things correctly a sim
I did:
> 2024-07-17 Bruno Haible
>
> stack-trace: Use libasan as an alternative to libbacktrace.
> * m4/stack-trace.m4 (gl_STACK_TRACE_EARLY): As a second choice, use
> libasan.
However, on NetBSD 10.0, every program that links with libasan exits
without even reaching main().
