• State Suggested Answer
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 25 subscribers
  • Views 12236 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM GCC 11.3 Rel1 newlib-nano linker warning _read is not implemented and will always fail

baboli

Hi! Upgrading to ARM GCC 11.3 from 7.3 and noticed these linker warnings on  bare metal embedded project. These linker warnings aren't on 7.3 or 11.2 ARM GCC versions. I'm having a tough time understanding why they are happening on ARM GCC 11.3 now.


Using the linker spec files:
nosys.specs
nano.specs

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg_nano.a(libc_a-closer.o): in function `_close_r':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/closer.c:47: warning: _close is not implemented and will always fail

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg_nano.a(libc_a-fstatr.o): in function `_fstat_r':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/fstatr.c:55: warning: _fstat is not implemented and will always fail

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg_nano.a(libc_a-isattyr.o): in function `_isatty_r':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/isattyr.c:52: warning: _isatty is not implemented and will always fail

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg_nano.a(libc_a-signalr.o): in function `_kill_r':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/signalr.c:53: warning: _kill is not implemented and will always fail

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg_nano.a(libc_a-lseekr.o): in function `_lseek_r':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/lseekr.c:49: warning: _lseek is not implemented and will always fail

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg_nano.a(libc_a-openr.o): in function `_open_r':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/openr.c:50: warning: _open is not implemented and will always fail

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg_nano.a(libc_a-readr.o): in function `_read_r':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/readr.c:49: warning: _read is not implemented and will always fail

Parents
  • 0

    Sounds great!  I've read that all you have to do to implement output to your favorite console-like device is "implement _write()"
    Of course, that ends up sucking in all of newlib's stdio, which is based on filsystem stuff, so it's pretty bloated.  And it references a bunch of other functions, even if you never use code paths that would call those functions to be executed (_read() for a character LCD, etc.)

    I though you used to have to implement a bunch of "stub" functions for each symbol you didn't care about.  Now, it seems that 'something' creates failing stub functions for you, and issues a warning that it's used a (failure-returning) stub.  That sounds ... mostly like I'd want it to be.

    (some stubs may need to return success, though.)

Reply
  • 0

    Sounds great!  I've read that all you have to do to implement output to your favorite console-like device is "implement _write()"
    Of course, that ends up sucking in all of newlib's stdio, which is based on filsystem stuff, so it's pretty bloated.  And it references a bunch of other functions, even if you never use code paths that would call those functions to be executed (_read() for a character LCD, etc.)

    I though you used to have to implement a bunch of "stub" functions for each symbol you didn't care about.  Now, it seems that 'something' creates failing stub functions for you, and issues a warning that it's used a (failure-returning) stub.  That sounds ... mostly like I'd want it to be.

    (some stubs may need to return success, though.)

Children
No data