Re: [PATCH] Generate signal names at runtime

Henrik Lindström <[email protected]>
Newsgroups org.kernel.vger.dash
Message-ID <[email protected]>
Getting the names from libc sounds ideal, but i don't think there's any way
to do that with musl, which is what i'm trying to cross compile to. That's
why i attempted a more universal solution in my patch, but perhaps there
would be interest in musl to add sigabbrev_np instead.

As for a fallback, shouldn't the goal be something more similar to my
attempt rather than the existing code? Silently building a broken version
of dash when cross compiling isn't ideal.

Thanks
Henrik

On 2024-04-27 13:47, Herbert Xu wrote:
> Henrik Lindström <[email protected]> wrote:
>> They were previously generated at buildtime by mksignames.c, but that
>> approach had two flaws:
>> 1. The signal names were generated for the host system rather than the
>>   target system, resulting in broken cross-compiled builds.
>> 2. The SIGRTMIN and SIGRTMAX macros are usually implemented as
>>   function calls and can only be surely known at runtime.
>>
>> The new implementation has been tested to generate identical signal names
>> as before on these systems:
>> * Debian 12 (glibc, odd number of realtime signals)
>> * Alpine 3.18 (musl, even number of realtime signals)
>> * FreeBSD 14
>>
>> Signed-off-by: Henrik Lindström <[email protected]>
> 
> Now that glibc has sigabbrev_np we should switch to using that
> on Linux, perhaps with the existing code as a fallback.  BSD
> has always had ways of getting the signal name, though it may
> not be very portable so we'd need different flavours if people
> cared enough to add them.
> 
> Thanks,
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.