Re: Request to clarify intended usage of libnosys in regards to linker warnings

Jeff Johnston <[email protected]> Thu, 26 Feb 2026 17:30:14 -0500
Newsgroups gmane.comp.lib.newlib
Message-ID <CAOox84uGPuC_HA+NruA-sVjsU_b8VkdbzDp0cNCgQeAxMafijQ@mail.gmail.com>
Hi Pavel,

The purpose of libnosys is to get your program to link by providing stubs
for various syscalls that newlib routines call.
The library is a convenience supplying "do nothing" stubs for unimplemented
functionality; hence the name: nosys.
Calling newlib library functions that use these stubs underneath will do
nothing or fail.  A platform could opt to use libnosys
in concert with other syscalls being supplied (e.g. I/O is not supported
but other syscalls are).

-- Jeff J.

On Thu, Feb 26, 2026 at 11:50 AM Pavel V. Melnikov <
[email protected]> wrote:

> Hello newlib team,
>
> I use libnosys in my Cortex-M0 project, and at some point I decided to
> upgrade GCC. Surprisingly, the linker started to emit warnings on
> unimplemented functions:
>
> ld.exe:
> C:/Users/melnik47/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/14.2.1/thumb/v6-m/nofp\libc_nano.a(libc_a-lseekr.o):
> in function `_lseek_r':
> lseekr.c:(.text._lseek_r+0x10): warning: _lseek is not implemented and
> will always fail
> ld.exe:
> C:/Users/melnik47/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/14.2.1/thumb/v6-m/nofp\libc_nano.a(libc_a-readr.o):
> in function `_read_r':
> readr.c:(.text._read_r+0x10): warning: _read is not implemented and
> will always fail
> ld.exe:
> C:/Users/melnik47/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/14.2.1/thumb/v6-m/nofp\libc_nano.a(libc_a-writer.o):
> in function `_write_r':
> writer.c:(.text._write_r+0x10): warning: _write is not implemented and
> will always fail
>
> After some googling, I found other people stumbling upon this, for example:
>
> https://stackoverflow.com/questions/73742774/gcc-arm-none-eabi-11-3-is-not-implemented-and-will-always-fail
>
> https://community.st.com/t5/stm32cubeide-mcus/linker-warnings-on-every-new-project/td-p/791910
>
> https://community.silabs.com/s/question/0D5Vm0000047to9KAA/linker-errors-on-update-to-gnu-arm-v1221
>
> Basically the result is that a working codebase starts to produce
> warnings after switching to a newer GCC.
> The matter is complicated by the fact that these linker warnings
> cannot be disabled with switches (as opposed to gcc warnings).
>
> It seems that ARM GCC has this issue starting with 11.3, and it's a
> combination of LD feature of printing .gnu.warning sections and
> libnosys feature of generating these sections.
> I tried to dig into the source code, and found out that the code for
> the warnings has been there for ~27 years, so something else must have
> changed in the toolchain building process on arm.com/linaro side
> around that time; the change causes the .gnu.warning. sections to be
> compiled in.starting with 11.3. Before that the newlib that comes with
> ARM GCC just did not have the warnings sections compiled in. I
> couldn't find what exactly changed in the build process (I asked for
> clarifications on arm.com forum), but I'm writing here to ask a
> different question.
>
> If the process produces warnings, it means that newlib/nosys
> developers do not intend the library to be used like this, right? So,
> what is the intended usage of libnosys, the one that does not produce
> linker warnings? Are developers expected to provide their own stubs in
> addition to libnosys stubs? Then the question is why use libnosys in
> the first place? Isn't its purpose to provide the stubs exactly so
> that the developers don't have to? I'm afraid I don't fully understand
> the intended usage of nosys, because before I tried to upgrade the
> compiler, I was linking with libnosys to get the behaviour (stubs that
> fail if called, without having to write them myself) that the new
> warning is warning me about.
>
> Best wishes,
>   Paul
> ___________________________________
>
> Best wishes,
> Paul Melnikov
>
>