Linker warning "_getentropy is not implemented and will always fail"

bastetfurry commented

2024-07-21 13:07:24 -05:00

(Migrated from github.com)

Trying to compile my project i get the following warning after an OS upgrade that also brought in a new version of GCC:

/usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc.a(libc_a-getentropyr.o): in function `_getentropy_r':
/build/newlib-38V0JC/newlib-4.4.0.20231231/build/arm-none-eabi/thumb/v6-m/nofp/newlib/../../../../../../newlib/libc/reent/getentropyr.c:48:(.text+0xe): warning: _getentropy is not implemented and will always fail
/usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc.a(libc_a-getentropyr.o): note: the message above does not take linker garbage collection into account

OS: Ubuntu 24.04
GCC: arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009
SDK: v1.6.1

Can this safely be ignored for now or can i do something against this, besides downgrading the compiler?

Trying to compile my project i get the following warning after an OS upgrade that also brought in a new version of GCC: ``` /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc.a(libc_a-getentropyr.o): in function `_getentropy_r': /build/newlib-38V0JC/newlib-4.4.0.20231231/build/arm-none-eabi/thumb/v6-m/nofp/newlib/../../../../../../newlib/libc/reent/getentropyr.c:48:(.text+0xe): warning: _getentropy is not implemented and will always fail /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc.a(libc_a-getentropyr.o): note: the message above does not take linker garbage collection into account ``` OS: Ubuntu 24.04 GCC: arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009 SDK: v1.6.1 Can this safely be ignored for now or can i do something against this, besides downgrading the compiler?

👍 2

kilograham commented

2024-07-21 17:22:07 -05:00

(Migrated from github.com)

i have not seen this; can you provide a minimal repro; is this with C++? are you calling something that might need getentropy?

i have not seen this; can you provide a minimal repro; is this with C++? are you calling something that might need `getentropy`?

jaguilar commented

2024-07-24 11:15:22 -05:00

(Migrated from github.com)

I saw this when I upgraded to the latest LTS of Ubuntu. It might be something that gets noticed with a new version of GCC and/or a new version of newlib?

lurch commented

2024-07-24 11:29:24 -05:00

(Migrated from github.com)

This at least shows that this problem isn't specific to just pico-sdk 😉

[This](https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-to-version-1-15-0-text-getentropy-r-0xe-warning/td-p/654866) at least shows that this problem isn't specific to _just_ `pico-sdk` :wink:

kilograham commented

2024-07-24 11:38:32 -05:00

(Migrated from github.com)

Yeah, i'm sure it is a problem with newlib however the reason I asked for a repro case, is that i couldn't reproduce it!! (and then work around it)

Yeah, i'm sure it is a problem with `newlib` however the reason I asked for a repro case, is that i couldn't reproduce it!! (and then work around it)

bastetfurry commented

2024-07-24 15:58:21 -05:00

(Migrated from github.com)

Sorry, haven't gotten around to create one yet. I don't want to FOSS my project just yet as i want it in a releaseworthy state, but if you could keep it under the lid until i am prepared to release it i could send you a copy.
I am using Elmchans FatFS as a library but everything else is just the normal Pico SDK and the normal C and C++ library.

Sorry, haven't gotten around to create one yet. I don't want to FOSS my project just yet as i want it in a releaseworthy state, but if you could keep it under the lid until i am prepared to release it i could send you a copy. I am using Elmchans FatFS as a library but everything else is just the normal Pico SDK and the normal C and C++ library.

bastetfurry commented

2024-07-24 16:01:19 -05:00

(Migrated from github.com)

As a sidenote, everything works as expected, so for now it seems one can ignore that warning.

kilograham commented

2024-07-24 16:02:02 -05:00

(Migrated from github.com)

ok, yeah maybe just worth looking at the .DIS file and see if there are any references to entropy

bastetfurry commented

2024-07-24 16:04:16 -05:00

(Migrated from github.com)

CLion says "Nope"

![Bildschirmfoto vom 2024-07-24 23-03-54](https://github.com/user-attachments/assets/a23f712e-ab8b-48b8-8b5d-d66ce938e096) CLion says "Nope"

bastetfurry commented

2024-07-24 16:07:37 -05:00

(Migrated from github.com)

Oh, cool, this is my whole project in assembler, thanks for showing me that! ❤️

dementedmonkey commented

2024-10-13 11:40:05 -05:00

(Migrated from github.com)

Not sure if you still need that minimal repro case, but here's mine:
CMakeLists.txt

cmake_minimum_required(VERSION 3.5)
include($ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake)
set(PICOTOOL_FETCH_FROM_GIT_PATH $ENV{PICO_SDK_PATH}/fetch)
set(target_proj bug)
project(${target_proj} C CXX)
pico_sdk_init()
add_executable(${target_proj} main.cpp )
target_link_libraries(${target_proj}  pico_stdlib )

main.cpp:

#include <queue>

int main()
{
    std::queue<int> queue;
}

build commands:

#! /bin/bash
rm -rf build
/usr/bin/cmake -DCMAKE_BUILD_TYPE:STRING=Debug -S. -B./build
/usr/bin/cmake --build ./build --config Debug --target all

It seems the -DCMAKE_BUILD_TYPE is part of the trigger. If that's not present, I don't see the warnings

Not sure if you still need that minimal repro case, but here's mine: `CMakeLists.txt` ``` cmake_minimum_required(VERSION 3.5) include($ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake) set(PICOTOOL_FETCH_FROM_GIT_PATH $ENV{PICO_SDK_PATH}/fetch) set(target_proj bug) project(${target_proj} C CXX) pico_sdk_init() add_executable(${target_proj} main.cpp ) target_link_libraries(${target_proj} pico_stdlib ) ``` `main.cpp`: ``` #include <queue> int main() { std::queue<int> queue; } ``` build commands: ``` #! /bin/bash rm -rf build /usr/bin/cmake -DCMAKE_BUILD_TYPE:STRING=Debug -S. -B./build /usr/bin/cmake --build ./build --config Debug --target all ``` It seems the `-DCMAKE_BUILD_TYPE` is part of the trigger. If that's not present, I don't see the warnings

lurch commented

2024-10-23 03:45:44 -05:00

(Migrated from github.com)

Thanks @dementedmonkey , I can confirm that I was able to reproduce this linker waning with your minimal example 👍 And I can also confirm that the warning doesn't appear if I change the CMAKE_BUILD_TYPE to Release.

@kilograham I used Docker to test this in different versions of Ubuntu last night, and the warning doesn't appear in Ubuntu 23.04 or Ubuntu 23.10 (which both use arm-none-eabi-gcc 12.2.1 and libnewlib-arm-none-eabi 3.3.0), but with Ubuntu 24.04 or Ubuntu 24.10 (which both use arm-none-eabi-gcc 13.2.1 and libnewlib-arm-none-eabi 4.4.0) the build-output includes this warning right at the end:

[ 98%] Building C object CMakeFiles/bug.dir/build_output/git.pico-sdk/src/rp2_common/pico_stdio_uart/stdio_uart.c.o
[100%] Linking CXX executable bug.elf
/usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/lib/thumb/v6-m/nofp/libg.a(libc_a-getentropyr.o): in function `_getentropy_r':
/build/newlib-38V0JC/newlib-4.4.0.20231231/build/arm-none-eabi/thumb/v6-m/nofp/newlib/../../../../../../newlib/libc/reent/getentropyr.c:48:(.text+0xe): warning: _getentropy is not implemented and will always fail
/usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/lib/thumb/v6-m/nofp/libg.a(libc_a-getentropyr.o): note: the message above does not take linker garbage collection into account
[100%] Built target bug

Thanks @dementedmonkey , I can confirm that I was able to reproduce this linker waning with your minimal example :+1: And I can also confirm that the warning _doesn't_ appear if I change the `CMAKE_BUILD_TYPE` to `Release`. @kilograham I used Docker to test this in different versions of Ubuntu last night, and the warning doesn't appear in Ubuntu 23.04 or Ubuntu 23.10 (which both use arm-none-eabi-gcc 12.2.1 and libnewlib-arm-none-eabi 3.3.0), but with Ubuntu 24.04 or Ubuntu 24.10 (which both use arm-none-eabi-gcc 13.2.1 and libnewlib-arm-none-eabi 4.4.0) the build-output includes this warning right at the end: ``` [ 98%] Building C object CMakeFiles/bug.dir/build_output/git.pico-sdk/src/rp2_common/pico_stdio_uart/stdio_uart.c.o [100%] Linking CXX executable bug.elf /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/lib/thumb/v6-m/nofp/libg.a(libc_a-getentropyr.o): in function `_getentropy_r': /build/newlib-38V0JC/newlib-4.4.0.20231231/build/arm-none-eabi/thumb/v6-m/nofp/newlib/../../../../../../newlib/libc/reent/getentropyr.c:48:(.text+0xe): warning: _getentropy is not implemented and will always fail /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/lib/thumb/v6-m/nofp/libg.a(libc_a-getentropyr.o): note: the message above does not take linker garbage collection into account [100%] Built target bug ```

mgw93 commented

2024-10-29 10:41:41 -05:00

(Migrated from github.com)

I may be able to contribute a hint here.

This code produces the warning:

struct test{
   test() : x{0} {};
   int x;
};

int main(){
   static test a;
}

This one does not:

struct test{
   constexpr test() : x{0} {};
   int x;
};

int main(){
   static test a;
}

The first version creates calls to __cxa_guard_acquire and __cxa_guard_release which seem to be intended to prevent access to not yet fully constructed static objects.
My hypothesis is that they somehow depend on randomness to randomize locking attempts.

I may be able to contribute a hint here. This code produces the warning: ``` struct test{ test() : x{0} {}; int x; }; int main(){ static test a; } ``` This one does not: ``` struct test{ constexpr test() : x{0} {}; int x; }; int main(){ static test a; } ``` The first version creates calls to `__cxa_guard_acquire` and `__cxa_guard_release` which seem to be intended to prevent access to not yet fully constructed static objects. My hypothesis is that they somehow depend on randomness to randomize locking attempts.

👍 2

edu-rossrobotics commented

2025-01-17 08:29:28 -06:00

(Migrated from github.com)

Hey, any update on that? In my case this is happening no matter which build type I'm using.

mgw93 commented

2025-01-22 04:12:20 -06:00

(Migrated from github.com)

Hey, any update on that? In my case this is happening no matter which build type I'm using.

If you are only interested in getting rid of the warning without understanding/solving the cause, you can pass -fno-threadsafe-statics to gcc.
As I wrote in my comment above, the issue is somehow related to static objects that get initialized at runtime.
Disabling the threadsafety features for them gets rid of the warning.

I currently have no idea how threadsafe statics and getentropy are related.

> Hey, any update on that? In my case this is happening no matter which build type I'm using. If you are only interested in getting rid of the warning without understanding/solving the cause, you can pass `-fno-threadsafe-statics` to gcc. As I wrote in my comment above, the issue is somehow related to static objects that get initialized at runtime. Disabling the threadsafety features for them gets rid of the warning. I currently have no idea how threadsafe statics and getentropy are related.

lurch commented

2025-01-22 04:34:56 -06:00

(Migrated from github.com)

My hypothesis is that they somehow depend on randomness to randomize locking attempts.

I currently have no idea how threadsafe statics and getentropy are related.

Maybe it's creating a random (unique) ID per thread / object, to check for collisions or something?

> My hypothesis is that they somehow depend on randomness to randomize locking attempts. > I currently have no idea how threadsafe statics and getentropy are related. Maybe it's creating a random (unique) ID per thread / object, to check for collisions or something?

kilograham commented

2025-02-03 12:20:17 -06:00

(Migrated from github.com)

moving to 2.2.0 as I'm not convinced this isn't a problem with this particular GCC/newlib version - also I think the warning is harmless

sdbbs commented

2025-02-10 15:17:24 -06:00

(Migrated from github.com)

I also stumbled upon this, and as I found the warnings irritating, I looked a bit further, and found Unable to link C++ application with libstdc++ when newlib is used (gcc 13 and perhaps also 12):

I suppose the origin of the problem is the definition of the getentropy
function in the newlib provided unistd.h, but what is the appropriate
fix for it?

Create a stub function that just returns -1 and sets errno=ENOSYS?

This should be fine.

As a definition of a "getentropy" function, I found https://codebrowser.dev/glibc/glibc/sysdeps/unix/sysv/linux/getentropy.c.html which starts with:

/* Write LENGTH bytes of randomness starting at BUFFER.  Return 0 on
   success and -1 on failure.  */
int
getentropy (void *buffer, size_t length)
{
  /* The interface is documented to return EIO for buffer lengths
     longer than 256 bytes.  */
  if (length > 256)
    {
      __set_errno (EIO);
      return -1;
    }
...

OK, so that kind of looks like it could be used as "a stub function that just returns -1 and sets errno=ENOSYS"; although, my actual linker error is (text reformatted for readability):

C:/msys64/mingw64/..../arm-none-eabi/bin/ld.exe: \
  C:/.../arm-none-eabi/lib/thumb/v6-m/nofp/libg.a(libc_a-getentropyr.o): \
    in function `_getentropy_r':
    
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/getentropyr.c:48:(.text+0xe): \
  warning: _getentropy is not implemented and will always fail
  
C:/..../arm-none-eabi/bin/ld.exe: \
  C:/..../arm-none-eabi/lib/thumb/v6-m/nofp/libg.a(libc_a-getentropyr.o): \
    note: the message above does not take linker garbage collection into account

... so it is _getentropy I need, with underscore, not just getentropy ...

Also, grepping through pico-sdk, I didn't see much of errno being mentioned. So in the end, I just added this to my pico-sdk main.c file, right before the definition of my main() function:

int _getentropy (void *buffer, size_t length)
{
  return -1;
}

... and the warning is now gone! I just hope this doesn't mess up other stuff - we'll see ...

Otherwise, I also found this suggestion in https://stackoverflow.com/questions/73742774/gcc-arm-none-eabi-11-3-is-not-implemented-and-will-always-fail :

Having said that, there is actually a method to get rid of the warnings from libnosys permanently:
Look for libnosys.a in your toolchain directory (in arm-none-abi case there will one for each architecture and float ABI), and delete .gnu.warning symbols from archives using:

arm-none-eabi-objcopy -w -R .gnu.warning.* libnosys.a

Note that this will irreversibly modify your toolchain files. Most likely in intended, and non-harmful way, but still. Use with caution.

If you use CMake to build your project I would consider creating PRE_LINK command that copies relevant libnosys, strips it of warnings, and link with it instead.

... but it kind of looked a bit extreme (plus for me, it is libg.a triggering the warning, not libnosys.a), so I thought I'd try this only if the above stub did not work - but the stub does seem to work did, so I left it there ...

I also stumbled upon this, and as I found the warnings irritating, I looked a bit further, and found [Unable to link C++ application with libstdc++ when newlib is used (gcc 13 and perhaps also 12)](https://sourceware.org/pipermail/newlib/2022/019920.html): > > I suppose the origin of the problem is the definition of the getentropy > > function in the newlib provided unistd.h, but what is the appropriate > > fix for it? > > - Create a stub function that just returns -1 and sets errno=ENOSYS? > > This should be fine. As a definition of a "getentropy" function, I found https://codebrowser.dev/glibc/glibc/sysdeps/unix/sysv/linux/getentropy.c.html which starts with: ```c /* Write LENGTH bytes of randomness starting at BUFFER. Return 0 on success and -1 on failure. */ int getentropy (void *buffer, size_t length) { /* The interface is documented to return EIO for buffer lengths longer than 256 bytes. */ if (length > 256) { __set_errno (EIO); return -1; } ... ``` OK, so that kind of looks like it could be used as "a stub function that just returns -1 and sets errno=ENOSYS"; although, my actual linker error is (text reformatted for readability): ```none C:/msys64/mingw64/..../arm-none-eabi/bin/ld.exe: \ C:/.../arm-none-eabi/lib/thumb/v6-m/nofp/libg.a(libc_a-getentropyr.o): \ in function `_getentropy_r': c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/getentropyr.c:48:(.text+0xe): \ warning: _getentropy is not implemented and will always fail C:/..../arm-none-eabi/bin/ld.exe: \ C:/..../arm-none-eabi/lib/thumb/v6-m/nofp/libg.a(libc_a-getentropyr.o): \ note: the message above does not take linker garbage collection into account ``` ... so it is `_getentropy` I need, with underscore, not just `getentropy` ... Also, grepping through pico-sdk, I didn't see much of `errno` being mentioned. So in the end, I just added this to my pico-sdk `main.c` file, right before the definition of my `main()` function: ```c int _getentropy (void *buffer, size_t length) { return -1; } ``` ... and the warning is now gone! I just hope this doesn't mess up other stuff - we'll see ... Otherwise, I also found this suggestion in https://stackoverflow.com/questions/73742774/gcc-arm-none-eabi-11-3-is-not-implemented-and-will-always-fail : > Having said that, there is actually a method to get rid of the warnings from libnosys permanently: Look for libnosys.a in your toolchain directory (in arm-none-abi case there will one for each architecture and float ABI), and delete .gnu.warning symbols from archives using: > > ```arm-none-eabi-objcopy -w -R .gnu.warning.* libnosys.a``` > > Note that this will irreversibly modify your toolchain files. Most likely in intended, and non-harmful way, but still. Use with caution. > > If you use CMake to build your project I would consider creating PRE_LINK command that copies relevant libnosys, strips it of warnings, and link with it instead. ... but it kind of looked a bit extreme (plus for me, it is libg.a triggering the warning, not libnosys.a), so I thought I'd try this only if the above stub did not work - but the stub does seem to work did, so I left it there ...

kilograham commented

2025-02-10 15:32:51 -06:00

(Migrated from github.com)

yeah, i mean we can return -1 for _get_entropy() or indeed returns something useful from pico_rand()

the returning of -1 is a good workaround if this is annoying you, but the reason I'm not committing that yet, is that it's not clear that it should be being called

yeah, i mean we can return -1 for `_get_entropy()` or indeed returns something useful from `pico_rand()` the returning of -1 is a good workaround if this is annoying you, but the reason I'm not committing that yet, is that it's not clear that it should be being called

👍 1

marek22k commented

2025-06-07 12:53:58 -05:00

(Migrated from github.com)

I have the same error when setting PICO_CXX_ENABLE_EXCEPTIONS to 1.

/usr/lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/lib/thumb/v8-m.main+fp/softfp/libg.a(libc_a-getentropyr.o): in function `_getentropy_r':
/build/arm-none-eabi-newlib/src/build-newlib/arm-none-eabi/thumb/v8-m.main+fp/softfp/newlib/../../../../../../newlib-4.5.0.20241231/newlib/libc/reent/getentropyr.c:48:(.text._getentropy_r+0x12): warning: _getentropy is not implemented and will always fail
/usr/lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/lib/thumb/v8-m.main+fp/softfp/libg.a(libc_a-getentropyr.o): note: the message above does not take linker garbage collection into account

Edit: CMAKE_BUILD_TYPE is Release in my project

So the current workaround is something like that?

int _getentropy(void * buffer, size_t length)
{
    if (length > 256)
    {
        errno = EINVAL;
        return -1;
    }
    uint8_t * byte_buffer = (uint8_t *) buffer;
    for (size_t index = 0; index < length; index++)
    {
        byte_buffer[index] = get_rand_32() & 0xFF;
    }
    return 0;
}

I have the same error when setting `PICO_CXX_ENABLE_EXCEPTIONS` to `1`. ``` /usr/lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/lib/thumb/v8-m.main+fp/softfp/libg.a(libc_a-getentropyr.o): in function `_getentropy_r': /build/arm-none-eabi-newlib/src/build-newlib/arm-none-eabi/thumb/v8-m.main+fp/softfp/newlib/../../../../../../newlib-4.5.0.20241231/newlib/libc/reent/getentropyr.c:48:(.text._getentropy_r+0x12): warning: _getentropy is not implemented and will always fail /usr/lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/lib/thumb/v8-m.main+fp/softfp/libg.a(libc_a-getentropyr.o): note: the message above does not take linker garbage collection into account ``` Edit: `CMAKE_BUILD_TYPE` is `Release` in my project So the current workaround is something like that? ```c int _getentropy(void * buffer, size_t length) { if (length > 256) { errno = EINVAL; return -1; } uint8_t * byte_buffer = (uint8_t *) buffer; for (size_t index = 0; index < length; index++) { byte_buffer[index] = get_rand_32() & 0xFF; } return 0; } ```

kilograham commented

2025-07-22 10:39:29 -05:00

(Migrated from github.com)

fix merged into develop; i could never reproduce, so assuming it works ;-)

Rows
Columns

Linker warning "_getentropy is not implemented and will always fail" #1768