Is there a way to ignore unused undefined references?

Question

Suppose I have two source files — UndefErr.cpp:

#include <cstdio>

void UndefFunc();
void Func2(){UndefFunc();}

void Func1(){printf("Hi\n");}

And the main.cpp:

void Func1();

int main(){
    Func1();
    return 0;
}

As you see in the UndefErr.cpp the Func2() going to trigger an error, for it using the undefined UndefFunc(). However the main function doesn't care about the Func2()! According to a relevant question I could pass an option --unresolved-symbols=ignore-in-object-files to the linker, but I want a kinda different thing. I need a linker to know if the undefined functions used somewhere, and only then fail.

The reason for asking such a strange question is that I'm trying to use a lwIP, and it is hard to understand all of its dependencies (I only need TCP/IP), and I can't find tutorials on the internet. So I thought I could compile most (or all) the .c files separately, and write some simple tests to see what it does. But this approach stumbles upon "undefined references", most of them probably irrelevant to the usecase.

Madewell

it does seem like the linker could just "figure out" if references even needed to be resolved... one solution though is if there are not a lot of functions to make it cumbersome you could just stub them out in main.cpp... e.g. void UndefFunc() {} – Knossos

@Knossos no, in the project very many functions. And the main problem that I don't know, which the functions isn't used, that's why I want somehow to automate it.. – Madewell

I don't understand the question. The linker is going to complain if it encounters an undefined function. – Wieldy

@BЈовић, yes, but if the undefined function is unused, it probably have more a sense to just ignore it. How to ignore such a references is just a question. – Madewell

Answer 1

With Gcc 4.8.2 I managed to link the code without errors with the following:

$ g++ -c main.cpp -O3 -flto
$ g++ -c UndefErr.cpp -O3 -flto
$ g++ main.o UndefErr.o -flto -O3 -o out

I know -flto will make the linker behave as if -fwhole-program was passed and the whole thing was a single compilation unit. And -fwhole-program, according to the manual, corresponds to the proper usage of static on functions, so allowing the unused function to be eliminated from the output (i.e. you assure the compiler all your functions will not be used by some other code, possibly dynamically loaded, and the only entry point you guarantee for your users is main()).

I had to add -O3, I am not sure why exactly, but the compiler was not very interested in inspecting the functions and eliminating dead code without it.

Guppy

Excellent, I never knew of this option! And yes, without the -O3 to be passed in compile time, the linker for some reason refuse to abort the unused functions. – Madewell

With MSYS2 build of MinGW GCC 5.3.0 I was able to achieve elimination of unused functions and therefore avoid "undefined reference" errors for symbols those functions referenced with -flto -Og compiler options – Nunes

Answer 2

The problem is that your undefined function is used. The object code for Func2 has been generated, there's a reference to unexisting UndefFunc, and it goes to the linker. Compiler has no way to understand that this function will always be undefined as there are multiple translation units.

The only way to avoid compilation error is to tell linker that you don't need object code for unused functions, so that it won't try to generate assembly for this case.

Durstin

I've seeked around, and I just found that probably I need two things: to use -fdata-sections -ffunction-sections as a flag in order for each function to be in it's own section(to allow a linker to see a references between a sections), and then linker need to know exact function (the main in my case), from which need to track a references. I also just found that the LD is have a scripting language, so probably here I go -- it seems, that no a standard way to do what I want. – Madewell

I think it worth mentioning, that in the above scenario I ought to track from the _start function, as it is the first function to be executed. Else I might to end up with a broken executable. – Madewell