_write et al. pulled in when linking C++ lib with bare-metal ARM C project

I've cross-compiled (for ARM Cortex-M4) an external C++ library/relinkable object file from source with the following flags:

  -fno-unwind-tables
  -ffunction-sections
  -fdata-sections
  -fmessage-length=0
  -std=c++11
  -fno-rtti
  -fno-exceptions
  -fno-threadsafe-statics
  -Wnon-virtual-dtor
  -fno-unwind-tables
  -ffreestanding
  -fno-non-call-exceptions
  -fno-use-cxa-atexit
  -fno-common
  -r

I've used the same flags to with -C to cross-compile a wrapper file that uses some of the library routines and exports a single extern "C" wrapped function. I then link the resulting object file with the aforementioned library by also passing additional flags:

-static -r -nostartfiles -nolibc -nodefaultlibs -nostdlib

I have a separate bare-metal C project in which I know call the exported C wrapper function and link it with the resulting library.

Doing this linking fails due to the following undefined references:

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-abort.o): in function `abort':
abort.c:(.text.abort+0xa): undefined reference to `_exit'

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-signalr.o): in function `_kill_r':
signalr.c:(.text._kill_r+0x12): undefined reference to `_kill'

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-signalr.o): in function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-writer.o): in function `_write_r':
writer.c:(.text._write_r+0x14): undefined reference to `_write'

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-closer.o): in function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-fstatr.o): in function `_fstat_r':
fstatr.c:(.text._fstat_r+0x12): undefined reference to `_fstat'

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-isattyr.o): in function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-lseekr.o): in function `_lseek_r':
lseekr.c:(.text._lseek_r+0x14): undefined reference to `_lseek'

../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-readr.o): in function `_read_r':
readr.c:(.text._read_r+0x14): undefined reference to `_read'

I'm able to resolve this by either passing --specs=nosys.specs or simply -lnosys to the linker.

Here's what's confusing me: looking at the produced ELF with either objdump --disassemble, strings or readelf -Ws I can see the offending references. However, if I look at the artifact of the original C project or any of the C++ artifacts I bundle together and link to the project I don't see any of these symbols.

My conclusion was thus that they must get pulled in by the virtue of linking in the C++ library, although I don't understand why and I don't want to blindly rely on nosyslib just to run into some hard-to-reason-about bugs later down the road.

> My conclusion was thus that they must get pulled in by the virtue of linking in the C++ library, although I don't understand why

Possibly because your version of g++ or of the c++ standard library is buggy with respect to freestanding mode.

Possibly because the library you are building includes one or more headers that are not on the allowed list for a freestanding implementation in the version of C++ you're compiling for. Or maybe it genuinely relies on the functions in question. In particular, if that library was not explicitly designed to be usable in conjunction with freestanding implementations, then it would be insanely lucky to find a combination of compile and link options that made it work correctly in a freestanding implementation. Note well that "compiles and links successfully" is only a small part of "works as intended".

Possibly some other issue.

> and I don't want to blindly rely on nosyslib just to run into some hard-to-reason-about bugs later down the road.

nosyslib provides stub versions of various system calls, which always fail without doing anything (else). This could be a source of bugs if the program does not properly check for and handle errors from syscalls, and / or if it in fact needs some of those syscalls to succeed in order to perform its intended work.

If those unresolved references are some kind of bogus artifact produced by your toolchain, meaning that no calls to those functions can ever actually be performed (see above comments about components being designed for freestanding mode), then nosyslib is probably a sturdy resolution. If the stub functions actually do get called then you're on much shakier ground. It may be hard to discern between these without a thorough review of all the code., including that of the "external" library.