Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] [RFC] libexecinfo broken on musl
@ 2022-12-18  5:23 oreo639
  2022-12-18  6:47 ` nekopsykose
                   ` (35 more replies)
  0 siblings, 36 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  5:23 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

New issue by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159

Description:
<!--
  if you are creating a bug report or package request, please fill out one of the forms here:
  https://github.com/void-linux/void-packages/issues/new/choose

  Don't request an update of a package, We have a script for that:
  https://alpha.de.repo.voidlinux.org/void-updates/void-updates.txt
  However, a quality pull request may help.
-->

This was something noticed by sgn and I when debugging the ldc crash on musl when testing the gcc 12 update.
When a segfault occurs, instead of printing the stack trace, libexecinfo either returns 0 or segfaults. (ultimately not really accomplishing anything)

This is something that was noticed in Alpine as well:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/10896

Alpine came to a decision between either fixing libexecinfo or removing it:
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36722

They chose the latter as they felt it wasn't useful for the end user and there was no loss of functionality vs staying with the broken libexeinfo.
https://gitlab.alpinelinux.org/alpine/aports/-/commit/50795a14dee639ce2dcc836e2b2baca9bad4a1b1

There is also a supposedly fixed version libexecinfo using libelf here:
https://git.ddd.rip/psykose/libexecinfo

The downside of using this implementation is that the abi is different meaning that all applications using libexecinfo will need to be recompiled. I also haven't tested it, so I can't confirm how well it works or if there are other considerations.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
@ 2022-12-18  6:47 ` nekopsykose
  2022-12-18  6:47 ` nekopsykose
                   ` (34 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  6:47 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356699095

Comment:
> The downside of using this implementation is that the abi is different meaning that all applications using libexecinfo will need to be recompiled.  

the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match.  

> supposedly fixed  

well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)  

> fixing libexecinfo  

this isn't really possible, i don't think. the primary reason is in the linked mailing list discussion- without adding `eh_frame`, it's impossible for the execinfo backtrace to resolve inside the libc. but this sort of low level stuff isn't really something i specialise in, so don't take that as a 100% authoritative statement.  

on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable. i don't remember in what scenarios it returned something non-empty, i'd have to look again.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
  2022-12-18  6:47 ` nekopsykose
@ 2022-12-18  6:47 ` nekopsykose
  2022-12-18  6:48 ` nekopsykose
                   ` (33 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  6:47 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356699095

Comment:
> The downside of using this implementation is that the abi is different meaning that all applications using libexecinfo will need to be recompiled.  

the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed)  

> supposedly fixed  

well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)  

> fixing libexecinfo  

this isn't really possible, i don't think. the primary reason is in the linked mailing list discussion- without adding `eh_frame`, it's impossible for the execinfo backtrace to resolve inside the libc. but this sort of low level stuff isn't really something i specialise in, so don't take that as a 100% authoritative statement.  

on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable. i don't remember in what scenarios it returned something non-empty, i'd have to look again.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
  2022-12-18  6:47 ` nekopsykose
  2022-12-18  6:47 ` nekopsykose
@ 2022-12-18  6:48 ` nekopsykose
  2022-12-18  6:53 ` nekopsykose
                   ` (32 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  6:48 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356699095

Comment:
> The downside of using this implementation is that the abi is different meaning that all applications using libexecinfo will need to be recompiled.  

the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)  

> supposedly fixed  

well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)  

> fixing libexecinfo  

this isn't really possible, i don't think. the primary reason is in the linked mailing list discussion- without adding `eh_frame`, it's impossible for the execinfo backtrace to resolve inside the libc. but this sort of low level stuff isn't really something i specialise in, so don't take that as a 100% authoritative statement.  

on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable. i don't remember in what scenarios it returned something non-empty, i'd have to look again.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (2 preceding siblings ...)
  2022-12-18  6:48 ` nekopsykose
@ 2022-12-18  6:53 ` nekopsykose
  2022-12-18  6:54 ` nekopsykose
                   ` (31 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  6:53 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356701773

Comment:
overall though, i never found a point to have libexecinfo backtrace(). things that generally make use of runtime backtracing to do useful things don't even use it- sanitizers and such implement this themselves via libunwind and friends. the only general case for `backtrace()` in programs is printing a stacktrace on crash/signal, and that is rarely going to be useful at all to anyone except the developers, for which a real backtrace via a debugger with full debug symbols will be much, much more useful than a minimal backtrace.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (3 preceding siblings ...)
  2022-12-18  6:53 ` nekopsykose
@ 2022-12-18  6:54 ` nekopsykose
  2022-12-18  6:59 ` nekopsykose
                   ` (30 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  6:54 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356701773

Comment:
overall though, i never found a point to have libexecinfo backtrace(). things that generally make use of runtime backtracing to do useful things don't even use it- sanitizers and such implement this themselves via libunwind and friends. the only general case for `backtrace()` in programs is printing a stacktrace on crash/signal, and that is rarely going to be useful at all to anyone except the developers, for whom a real backtrace via a debugger with full debug symbols will be much, much more useful than a minimal backtrace.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (4 preceding siblings ...)
  2022-12-18  6:54 ` nekopsykose
@ 2022-12-18  6:59 ` nekopsykose
  2022-12-18  7:16 ` nekopsykose
                   ` (29 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  6:59 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356709426

Comment:
(and that's separate to .eh_frame being useful for other things- that in itself would enable more things to work, and hopefully not have anyone use libexecinfo still, but i don't think dalias will ever ack it into musl)

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (5 preceding siblings ...)
  2022-12-18  6:59 ` nekopsykose
@ 2022-12-18  7:16 ` nekopsykose
  2022-12-18  8:41 ` oreo639
                   ` (28 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  7:16 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356709426

Comment:
(and that's separate to .eh_frame being (perhaps) useful for other things- that in itself would enable more things to work (dubiously), and hopefully not have anyone use libexecinfo still, but i don't think dalias will ever ack it into musl)

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (6 preceding siblings ...)
  2022-12-18  7:16 ` nekopsykose
@ 2022-12-18  8:41 ` oreo639
  2022-12-18  8:43 ` oreo639
                   ` (27 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:41 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I initially assumed that some function that used to be provided isn't being provided anymore, but yeah, that is a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

I didn't mean that to say that it didn't work, I just meant that as I haven't looked into it much, I should have been more clear.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said trying to use it right now with a use-after-free seems to result in nothing happening.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (7 preceding siblings ...)
  2022-12-18  8:41 ` oreo639
@ 2022-12-18  8:43 ` oreo639
  2022-12-18  8:43 ` oreo639
                   ` (26 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:43 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I initially assumed that some function that used to be provided isn't being provided anymore, but yeah, that is a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, I what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said trying to use it right now with a use-after-free seems to result in nothing happening.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (8 preceding siblings ...)
  2022-12-18  8:43 ` oreo639
@ 2022-12-18  8:43 ` oreo639
  2022-12-18  8:44 ` oreo639
                   ` (25 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:43 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I initially assumed that some function that used to be provided isn't being provided anymore, but yeah, that is a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said trying to use it right now with a use-after-free seems to result in nothing happening.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (9 preceding siblings ...)
  2022-12-18  8:43 ` oreo639
@ 2022-12-18  8:44 ` oreo639
  2022-12-18  8:45 ` oreo639
                   ` (24 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:44 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that is clearly a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said trying to use it right now with a use-after-free seems to result in nothing happening.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (10 preceding siblings ...)
  2022-12-18  8:44 ` oreo639
@ 2022-12-18  8:45 ` oreo639
  2022-12-18  8:45 ` oreo639
                   ` (23 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:45 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that is clearly a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said. I tried to use it with an intentional use-after-free seems to result in nothing happening. (with the current broken libexecinfo)

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (11 preceding siblings ...)
  2022-12-18  8:45 ` oreo639
@ 2022-12-18  8:45 ` oreo639
  2022-12-18  8:48 ` oreo639
                   ` (22 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:45 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that is clearly a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said. I tried to use it with an intentional use-after-free seems to result in nothing happening. (with the current libexecinfo)

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (12 preceding siblings ...)
  2022-12-18  8:45 ` oreo639
@ 2022-12-18  8:48 ` oreo639
  2022-12-18  8:49 ` oreo639
                   ` (21 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:48 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that is clearly a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said. I tried to use it with an intentional use-after-free seems to result in nothing happening. (with the current libexecinfo)

> on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable

I don't think we use `-fomit-frame-pointer` correct me if I am wrong.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (13 preceding siblings ...)
  2022-12-18  8:48 ` oreo639
@ 2022-12-18  8:49 ` oreo639
  2022-12-18  8:50 ` oreo639
                   ` (20 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:49 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that is clearly a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said. I tried to use it with an intentional use-after-free seems to result in nothing happening. (with the current libexecinfo)

> on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable

I don't think we use `-fomit-frame-pointer`, correct me if I am wrong.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (14 preceding siblings ...)
  2022-12-18  8:49 ` oreo639
@ 2022-12-18  8:50 ` oreo639
  2022-12-18  8:53 ` oreo639
                   ` (19 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:50 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that is clearly a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said. I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening. (with the current libexecinfo)

> on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable

I don't think we use `-fomit-frame-pointer`, correct me if I am wrong.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (15 preceding siblings ...)
  2022-12-18  8:50 ` oreo639
@ 2022-12-18  8:53 ` oreo639
  2022-12-18  8:54 ` nekopsykose
                   ` (18 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:53 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that is clearly a different issue. (probably because I didn't have pkg-config in the hostmakedepends lol)

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said. I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening. (with the current libexecinfo)

> on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable

I don't think we use `-fomit-frame-pointer`, correct me if I am wrong.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (16 preceding siblings ...)
  2022-12-18  8:53 ` oreo639
@ 2022-12-18  8:54 ` nekopsykose
  2022-12-18  8:54 ` oreo639
                   ` (17 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  8:54 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356740819

Comment:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
```

that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.  

> I don't think we use -fomit-frame-pointer, correct me if I am wrong.  
it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.  

> It is currently required by LLVM for GWP-ASan.  
ah.. right, that was the /single/ only thing i found that needed it for something non-generic :) i ended up merely disabling it for alpine.
i think q66 was working on getting that to work without execinfo, to get it working on chimera (also musl based and without libexecinfo).

> I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening.  

most likely, it doesn't get anything via backtrace() so it gets no info to be useful due to the other issues here.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (17 preceding siblings ...)
  2022-12-18  8:54 ` nekopsykose
@ 2022-12-18  8:54 ` oreo639
  2022-12-18  8:54 ` nekopsykose
                   ` (16 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:54 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that's just because I didn't have pkg-config in the hostmakedepends lol

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said. I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening. (with the current libexecinfo)

> on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable

I don't think we use `-fomit-frame-pointer`, correct me if I am wrong.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (18 preceding siblings ...)
  2022-12-18  8:54 ` oreo639
@ 2022-12-18  8:54 ` nekopsykose
  2022-12-18  8:55 ` nekopsykose
                   ` (15 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  8:54 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356740819

Comment:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
```

that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.  

> I don't think we use -fomit-frame-pointer, correct me if I am wrong.  

it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.  

> It is currently required by LLVM for GWP-ASan.  
ah.. right, that was the /single/ only thing i found that needed it for something non-generic :) i ended up merely disabling it for alpine.
i think q66 was working on getting that to work without execinfo, to get it working on chimera (also musl based and without libexecinfo).

> I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening.  

most likely, it doesn't get anything via backtrace() so it gets no info to be useful due to the other issues here.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (19 preceding siblings ...)
  2022-12-18  8:54 ` nekopsykose
@ 2022-12-18  8:55 ` nekopsykose
  2022-12-18  8:55 ` oreo639
                   ` (14 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18  8:55 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356740819

Comment:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
```

that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.  

> I don't think we use -fomit-frame-pointer, correct me if I am wrong.  

it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.  

> It is currently required by LLVM for GWP-ASan.  

ah.. right, that was the /single/ only thing i found that needed it for something non-generic :) i ended up merely disabling it for alpine.
i think q66 was working on getting that to work without execinfo, to get it working on chimera (also musl based and without libexecinfo).

> I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening.  

most likely, it doesn't get anything via backtrace() so it gets no info to be useful due to the other issues here.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (20 preceding siblings ...)
  2022-12-18  8:55 ` nekopsykose
@ 2022-12-18  8:55 ` oreo639
  2022-12-18  9:41 ` oreo639
                   ` (13 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  8:55 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that's definitely a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
That being said. I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening. (with the current libexecinfo)

> on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable

I don't think we use `-fomit-frame-pointer`, correct me if I am wrong.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (21 preceding siblings ...)
  2022-12-18  8:55 ` oreo639
@ 2022-12-18  9:41 ` oreo639
  2022-12-18  9:49 ` oreo639
                   ` (12 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:41 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356759155

Comment:
> it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.

Ah, thanks.

> that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.

Yeah, I initially ran into the issue when I was debugging why ldc was segfaulting on musl but only when compiled with DMD, and I was too lazy to test it again, sorry.

The issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (22 preceding siblings ...)
  2022-12-18  9:41 ` oreo639
@ 2022-12-18  9:49 ` oreo639
  2022-12-18  9:50 ` oreo639
                   ` (11 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:49 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356759155

Comment:
> it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.

Ah, thanks.

> that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.

Yeah, I initially ran into the issue when I was debugging why ldc was segfaulting on musl but only when compiled with DMD, and I was too lazy to test it again, sorry.

The issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.

Also, I did get the infinite loop when testing GWP-ASan. I accidentally saved my test to the wrong file :facepalm:

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (23 preceding siblings ...)
  2022-12-18  9:49 ` oreo639
@ 2022-12-18  9:50 ` oreo639
  2022-12-18  9:50 ` oreo639
                   ` (10 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:50 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356759155

Comment:
> it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.

Ah, thanks.

> that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.

Yeah, I initially ran into the issue when I was debugging why ldc was segfaulting on musl but only when compiled with DMD, and I was too lazy to test it again, sorry.

The issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.

Also, I did get the infinite loop when testing GWP-ASan. I accidentally saved my test to the wrong file last time :facepalm:

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (24 preceding siblings ...)
  2022-12-18  9:50 ` oreo639
@ 2022-12-18  9:50 ` oreo639
  2022-12-18  9:50 ` oreo639
                   ` (9 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:50 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356759155

Comment:
> it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.

Ah, thanks.

> that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.

Yeah, I initially ran into the issue when I was debugging why ldc was segfaulting on musl but only when compiled with DMD, and I was too lazy to test it again, sorry.

The issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.

Also, I did get the infinite loop when testing GWP-ASan. The reason nothing happened before was because I accidentally saved my test to the wrong file last time :facepalm:

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (25 preceding siblings ...)
  2022-12-18  9:50 ` oreo639
@ 2022-12-18  9:50 ` oreo639
  2022-12-18  9:51 ` oreo639
                   ` (8 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:50 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356759155

Comment:
> it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.

Ah, thanks.

> that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.

Yeah, the issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.

Also, I did get the infinite loop when testing GWP-ASan. The reason nothing happened before was because I accidentally saved my test to the wrong file last time :facepalm:

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (26 preceding siblings ...)
  2022-12-18  9:50 ` oreo639
@ 2022-12-18  9:51 ` oreo639
  2022-12-18  9:52 ` oreo639
                   ` (7 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:51 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2597 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that's definitely a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
~~That being said. I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening. (with the current libexecinfo)~~
Edit: I do get the infinite loop in GWP-ASan.

> on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable

I don't think we use `-fomit-frame-pointer`, correct me if I am wrong.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (27 preceding siblings ...)
  2022-12-18  9:51 ` oreo639
@ 2022-12-18  9:52 ` oreo639
  2022-12-18  9:53 ` oreo639
                   ` (6 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:52 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356759155

Comment:
> it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.

Thanks.

> that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.

Yeah, the issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.

Also, I did get the infinite loop when testing GWP-ASan. The reason nothing happened before was because I accidentally saved my test to the wrong file last time :facepalm:

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (28 preceding siblings ...)
  2022-12-18  9:52 ` oreo639
@ 2022-12-18  9:53 ` oreo639
  2022-12-18  9:54 ` oreo639
                   ` (5 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:53 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356738883

Comment:
Thank your so much for the clarifications.

> the entire ABI is just the backtrace functions. if you mean the SONAME, that can freely be made to match. (i.e., there is no recompiling needed). (..maybe there was a stray other symbol? i remember seeing one, but nothing ever calls it in practice so an empty stub could be added)

Yeah, my bad.
When I was testing it with compiling ldc (libexecinfo is used by llvm12) I got:
```
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_strptr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getehdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_begin: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getsym: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_nextscn: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_getdata: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_version: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_end: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: gelf_getshdr: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errmsg: symbol not found
Error relocating /usr/bin/../lib/../lib/libexecinfo.so.1: elf_errno: symbol not found
```
At the time I assumed that some function that used to be provided isn't being provided anymore, but yeah, that's definitely a different issue.

> well.. it doesn't segfault, that's about all i can really say for it. it's a port of the latest version of libexecinfo from freebsd, which happens to have moved to libelf since the last one that was used (also a port)

To be clear, what I meant by that was that I haven't really tested it due to the above issue.

> i never found a point to have libexecinfo backtrace()

Fair.
It is currently required by LLVM for GWP-ASan. I personally had never used it (or heard of it) before looking into said issue.
~~That being said. I tried to use it with an intentional use-after-free which, for me, resulted in nothing happening. (with the current libexecinfo)~~
Edit: I do get the reported infinite loop in GWP-ASan.

> on top of that, i'm not sure how well that backtrace works with `-fomit-frame-pointer -O2` on an executable

I don't think we use `-fomit-frame-pointer`, correct me if I am wrong.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (29 preceding siblings ...)
  2022-12-18  9:53 ` oreo639
@ 2022-12-18  9:54 ` oreo639
  2022-12-18  9:59 ` oreo639
                   ` (4 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:54 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356759155

Comment:
> it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.

Thanks.

> that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.

Yeah, the issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.

Also, I did get the infinite loop when testing GWP-ASan. The reason nothing happened before was because I accidentally saved my test to the wrong file last time :facepalm:

Thanks again for the clarifications. imo, it is probably a good idea to drop libexecinfo.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (30 preceding siblings ...)
  2022-12-18  9:54 ` oreo639
@ 2022-12-18  9:59 ` oreo639
  2022-12-18 10:17 ` nekopsykose
                   ` (3 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2022-12-18  9:59 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356759155

Comment:
> it's the default on most(?) architectures for -O1 and higher. the manpage just says O1, but someone told me not everywhere- i'd have to look at the code to say for sure, but generally it's there anyway.

Ah, thanks.

> that would be caused by a missing libelf.so not being found, as those are libelf symbols, no? there would be a failed to find message somewhere else in the output.

Yeah, the issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.

Also, I did get the infinite loop when testing GWP-ASan. The reason nothing happened before was because I accidentally saved my test to the wrong file last time :facepalm:

Thanks again for the clarifications. imo, it is probably a good idea to drop libexecinfo.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (31 preceding siblings ...)
  2022-12-18  9:59 ` oreo639
@ 2022-12-18 10:17 ` nekopsykose
  2023-03-19  2:02 ` github-actions
                   ` (2 subsequent siblings)
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2022-12-18 10:17 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1356765853

Comment:
> Yeah, the issue was just that -lelf wasn't getting added to the linker flags since I didn't have pkg-config in the hostmakedepends.  

i was curious how a link could succeed if you didn't have a valid link line- then realised linkers by default don't fail on missing symbols without passing `-z now`. that makes it fail instantly if the output is invalid and can't resolve symbols, i guess not everyone has it in the LDFLAGS as `-Wl,-z,now` all the time..

> Also, I did get the infinite loop when testing GWP-ASan. The reason nothing happened before was because I accidentally saved my test to the wrong file last time 

gets me every time too :)

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (32 preceding siblings ...)
  2022-12-18 10:17 ` nekopsykose
@ 2023-03-19  2:02 ` github-actions
  2023-03-19  2:18 ` oreo639
  2023-03-19  3:06 ` nekopsykose
  35 siblings, 0 replies; 37+ messages in thread
From: github-actions @ 2023-03-19  2:02 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

New comment by github-actions[bot] on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1475069589

Comment:
Issues become stale 90 days after last activity and are closed 14 days after that.  If this issue is still relevant bump it or assign it.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (33 preceding siblings ...)
  2023-03-19  2:02 ` github-actions
@ 2023-03-19  2:18 ` oreo639
  2023-03-19  3:06 ` nekopsykose
  35 siblings, 0 replies; 37+ messages in thread
From: oreo639 @ 2023-03-19  2:18 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1475074741

Comment:
bump

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC] libexecinfo broken on musl
  2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
                   ` (34 preceding siblings ...)
  2023-03-19  2:18 ` oreo639
@ 2023-03-19  3:06 ` nekopsykose
  35 siblings, 0 replies; 37+ messages in thread
From: nekopsykose @ 2023-03-19  3:06 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

New comment by nekopsykose on void-packages repository

https://github.com/void-linux/void-packages/issues/41159#issuecomment-1475083502

Comment:
smh stalebots in current year

^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2023-03-19  3:06 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-18  5:23 [ISSUE] [RFC] libexecinfo broken on musl oreo639
2022-12-18  6:47 ` nekopsykose
2022-12-18  6:47 ` nekopsykose
2022-12-18  6:48 ` nekopsykose
2022-12-18  6:53 ` nekopsykose
2022-12-18  6:54 ` nekopsykose
2022-12-18  6:59 ` nekopsykose
2022-12-18  7:16 ` nekopsykose
2022-12-18  8:41 ` oreo639
2022-12-18  8:43 ` oreo639
2022-12-18  8:43 ` oreo639
2022-12-18  8:44 ` oreo639
2022-12-18  8:45 ` oreo639
2022-12-18  8:45 ` oreo639
2022-12-18  8:48 ` oreo639
2022-12-18  8:49 ` oreo639
2022-12-18  8:50 ` oreo639
2022-12-18  8:53 ` oreo639
2022-12-18  8:54 ` nekopsykose
2022-12-18  8:54 ` oreo639
2022-12-18  8:54 ` nekopsykose
2022-12-18  8:55 ` nekopsykose
2022-12-18  8:55 ` oreo639
2022-12-18  9:41 ` oreo639
2022-12-18  9:49 ` oreo639
2022-12-18  9:50 ` oreo639
2022-12-18  9:50 ` oreo639
2022-12-18  9:50 ` oreo639
2022-12-18  9:51 ` oreo639
2022-12-18  9:52 ` oreo639
2022-12-18  9:53 ` oreo639
2022-12-18  9:54 ` oreo639
2022-12-18  9:59 ` oreo639
2022-12-18 10:17 ` nekopsykose
2023-03-19  2:02 ` github-actions
2023-03-19  2:18 ` oreo639
2023-03-19  3:06 ` nekopsykose

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).