[PATCH] libc: fix _dummy_signal_syscalls name in signalr.c
Jeff Johnston
jjohnstn@redhat.com
Tue Jan 20 16:55:33 GMT 2026
IIRC, the dummy variables were to prevent the object files from being empty
and causing issues with one of the build tools we were using (likely
libtool).
-- Jeff J.
On Tue, Jan 20, 2026 at 4:47 AM Corinna Vinschen <vinschen@redhat.com>
wrote:
> On Jan 19 12:11, andrew@andrewoates.com wrote:
> > From: Andrew Oates <andrew@andrewoates.com>
> >
> > I don't understand the purpose of these dummy variables, but they date
> > back to 2000 and the import of the 2000-02-17 snapshot.
>
> Me neither. I defer to Jeff here.
>
>
> Corinna
>
> > _dummy_link_syscalls is defined in two places, here and linkr.c. This
> > updates the symbol name to match the file, so we don't define the same
> > symbol in two places.
> > ---
> > newlib/libc/reent/signalr.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/newlib/libc/reent/signalr.c b/newlib/libc/reent/signalr.c
> > index 863ae7400..e4945102f 100644
> > --- a/newlib/libc/reent/signalr.c
> > +++ b/newlib/libc/reent/signalr.c
> > @@ -17,7 +17,7 @@
> >
> > #ifdef REENTRANT_SYSCALLS_PROVIDED
> >
> > -int _dummy_link_syscalls = 1;
> > +int _dummy_signal_syscalls = 1;
> >
> > #else
> >
> > --
> > 2.52.0
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20260120/00fe1799/attachment.htm>
More information about the Newlib
mailing list