Open ndim opened 2 years ago
Using AC_LINK_IFELSE
would be actually useful to find out whenever beep needs to be linked with -latomic
. It's the case with at least armv5te target. Either that or move to event loop (your other draft) as it removes the use of volatile sig_atomic_t global_abort
.
Hmm, above is caused by address sanitizer which requires both -lubsan
and -latomic
. There is nothing to handle additional libraries currently, so I'll just provide local.mk to disable all that additional checks. However there are few nits to fix and I will open PR for them. You may disregard my comments now.
beep
does not use any symbols regarding atomic stuff which might be supplied by a library. beep
only uses the sig_atomic_t
type at compile time, so I do not see how linking any library to beep
would make sense.
Besides, what system using a armv5te
target CPU can make use of beep
? It cannot have classic PC speaker hardware, so beep
would at least need to add a well known device name to look for.
So... if I understand you correctly, you basically want to have a local.mk
containing
CFLAGS = -fsanitize=undefined
LDADD = -lubsan -latomic
but only add the LDADD
part for architecture/compiler/libc environments where it is actually needed?
You may see actual linking error and explanation here: https://lore.ptxdist.org/ptxdist/ZjNw3VmNCgGpJwsq@lenoch/T/#m080d02abdd4a8f7432d73fa5fedfc26f949cdcf4
Solved this way: https://git.pengutronix.de/cgit/ptxdist/commit/?id=0b9fb169815fdea1de4901ce0434a048affbff39
While GNUMakefile
could certainly use something like Busybox' scripts/trylink
I'm considering that an overkill, so no action needed on beep
part :)
Also note kernel contains drivers/input/misc/gpio-beeper.c
and drivers/input/misc/pwm-beeper.c
both being perfectly useable with beep
, so many thanks for still maintaining it!
Also note kernel contains
drivers/input/misc/gpio-beeper.c
anddrivers/input/misc/pwm-beeper.c
both being perfectly useable withbeep
, so many thanks for still maintaining it!
If you have an idea where to find the well-known device names for those hardware devices, please let me know so I can add them to beep.
At this time, beep only knows to look for the PC speaker device /dev/input/by-path/platform-pcspkr-event-spkr
.
I will take a look at the build stuff later.
Even though building with an Automake based buildsystem takes a lot more time, it is still convenient to follow standard conventions like having a configure script to run.
Not sure I really want to switch. The current GNUmakefile is quite neat with its installing only what actually is actually necessary and stuff.