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

Hello Jeff, thank you for clarifying.

On Thu, 26 Feb 2026 at 23:30, Jeff Johnston <[email protected]> wrote:
>
> 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).

Ok, so it means that my understanding is correct. The question is then
how to get rid of the warnings when libnosys is used as intended?

>
> -- 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
>>