Can GCC not complain about undefined references?

Under what situation is it possible for GCC to not throw an "undefined reference" link error message when trying to call made-up functions?

For example, a situation in which this C code is compiled and linked by GCC:

void function()
{
    made_up_function_name();
    return;
}

...even though made_up_function_name is not present anywhere in the code (not headers, source files, declarations, nor any third party library).

Can that kind of code be accepted and compiled by GCC under certain conditions, without touching the actual code? If so, which?

Thanks.

EDIT: no previous declarations or mentions to made_up_function_name are present anywhere else. Meaning that a grep -R of the whole filesystem will only show that exact single line of code.

Yes, it is possible to avoid reporting undefined references - using --unresolved-symbols linker option.

g++ mm.cpp -Wl,--unresolved-symbols=ignore-in-object-files

From man ld

> --unresolved-symbols=method

> Determine how to handle unresolved symbols. There are four > possible values for method: > > > > ignore-all > Do not report any unresolved symbols. > > report-all > Report all unresolved symbols. This is the default. > > ignore-in-object-files > Report unresolved symbols that are contained in shared > libraries, but ignore them if they come from regular object > files. > > ignore-in-shared-libs > Report unresolved symbols that come from regular object > files, but ignore them if they come from shared libraries. This > can be useful when creating a dynamic binary and it is known > that all the shared libraries that it should be referencing > are included on the linker's command line. > > The behaviour for shared libraries on their own can also be > controlled by the --[no-]allow-shlib-undefined option. > > Normally the linker will generate an error message for each > reported unresolved symbol but the option --warn-unresolved-symbols can > change this to a warning.

TL;DR It can not complain, but you don't want that. Your code will crash if you force the linker to ignore the problem. It'd be counterproductive.

Your code relies on the ancient C (pre-C99) allowing functions to be implicitly declared at their point of use. Your code is semantically equivalent to the following code:

void function()
{
    int made_up_function_name(...); // The implicit declaration

    made_up_function_name(); // Call the function
    return;
}

The linker rightfully complains that the object file that contains the compiled function() refers to a symbol that wasn't found anywhere else. You have to fix it by providing the implementation for made_up_function_name() or by removing the nonsensical call. That's all there's to it. No linker-fiddling involved.

If you declare the prototype of the function before using it , it shold compile. Anyway the error while linking will remain.

void made_up_function_name();
void function()
{
    made_up_function_name();
    return;
}

And then there is this nastiness with the -D flag passed to GCC.

$cat undefined.c
void function()
{
    made_up_function_name();
    return;
}


int main(){
}

$gcc undefined.c -Dmade_up_function_name=atexit
$

Just imagine looking for the definition of made_up_function_name- it appears nowhere yet "does things" in the code. I can't think of a nice reason to do this exact thing in code.

The -D flag is a powerful tool for changing code at compile time.

When you build with the linker flag -r or --relocatable it will also not produce any "undefined reference" link error messages.

This is because -r will link different objects in a new object file to be linked at a later stage.

If function() is never called, it might not be included in the executable, and the function called from it is not searched for either.

The "standard" algorithm according to which POSIX linkers operate leaves open the possibility that the code will compile and link without any errors. See here for details: https://stackoverflow.com/a/11894098/187690

In order to exploit that possibility the object file that contains your function (let's call it f.o) should be placed into a library. That library should be mentioned in the command line of the compiler (and/or linker), but by that moment no other object file (mentioned earlier in the command line) should have made any calls to function or any other function present in f.o. Under such circumstances linker will see no reason to retrieve f.o from the library. Linker will completely ignore f.o, completely ignore function and, therefore, remain completely oblivious of the call to made_up_function_name. The code will compile even though made_up_function_name is not defined anywhere.