Strange linking behaviour with static libraries

[conkerkh]

Hello,
I have a strange situation which I'm trying to figure out, I have a static library that also implements retargeting of _read and _write syscalls by using nosys specs on ARM GCC compiler. The idea is that you can retarget printf/scanf output/input to some other source like UART or in my case Segger RTT.

In my case, there is a syscalls.c file that has my specific syscalls implementation. If I don't call a single function directly in my object files, those custom syscalls from the static library will be completely ignored during the linking process. However, calling even one function somewhere in object files will cause all other functions from the static library to be linked by the linker, even if those other functions were not called directly. In this case, changing the order of the libraries makes no difference I believe this is something else from linking order.

[SiliconWizard]

This is pretty much the default behavior with GCC - actually it's more to do with the linker, which is from binutils.
It does bite indeed, but the linker does not prune unused functions by default. Be they in static libraries or in your object files - that is, functions that are not 'static'. Same for data.

The most common way of doing what you want done is to add the following options to GCC for compiling: -ffunction-sections -fdata-sections
and the following option to the linker: --gc-sections

What it does is basically put every function (and global non-static variables) in their own section, and then the linker prunes the unused sections. Yeah, a bit heavy, but that's how it's done.

[conkerkh]

This is pretty much the default behavior with GCC - actually it's more to do with the linker, which is from binutils.
It does bite indeed, but the linker does not prune unused functions by default. Be they in static libraries or in your object files - that is, functions that are not 'static'. Same for data.

The most common way of doing what you want done is to add the following options to GCC for compiling: -ffunction-sections -fdata-sections
and the following option to the linker: --gc-sections

What it does is basically put every function (and global non-static variables) in their own section, and then the linker prunes the unused sections. Yeah, a bit heavy, but that's how it's done.

So it's probably my fault I wasn't clear enough. The situation I have is actually opposite I use -ffunction-sections -fdata-sections for g++/gcc and --gc-sections for linker. I'm linking with --specs=nosys.specs this allows to retarget _read/_write function prototypes and others.

In my case, I created static libraries (archives) which contain implementations of _read and _write functions.

However, during the linking process whole file with mentioned implementation from the static library is ignored. If I call explicitly _read or _write functions in normal object files passed to the linker, suddenly all the functions in the file from the previously created static library are included in the final elf file.

[conkerkh]

This StackOverflow topic also precisely describes my problem: https://stackoverflow.com/questions/47500472/functions-which-are-in-the-linked-library-are-not-seen-in-executable, also the solution to place libc before my linked library works fine. Well if anyone has some good resources on the linking process it would be great.

[SiliconWizard]

Ah, you're right, your first post got me confused. The next two helped.

I've never defined those functions (like _read, _write, _sbrk...) in a library, but just in source files directly compiled and linked, and never ran into this issue.

But I think your problem has everything to do with the way the linker works - the order of libraries does matter indeed (and I admit this can still confuse me occasionally, when there are dependencies between libraries.)

You will find a more detailed answer there: https://stackoverflow.com/questions/11893996/why-does-the-order-of-l-option-in-gcc-matter