Still builds successfully when defining duplicate functions (IDFGH-12819)

[ElectricThanhTung]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.2.1

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

None

What is the expected behavior?

Build fail

What is the actual behavior?

Sitll build success

Steps to reproduce.

1. Define 2 functions (non-static function) with the same name but in 2 different source files
2. Call that function in app_main
3. Build source code
   

Build or installation Logs.

No response

More Information.

Project reproduces the issue:
sample_project.zip

[KaeLL]

Here's one better: building your sample_project on release/4.4 triggers an infinite loop in the build process.

[igrr]

The original issue reported by @ElectricThanhTung is explained by the fact that once the linker finds the function Test in one of the object files, it has no reason to consider the other object file for linking, as it doesn't resolve any of the unresolved references. This is the behavior of GNU linker for object files inside static libraries.

If both source files contained symbols required to resolve undefined references, then the linker would try to include both object files into the output file, resulting in the duplicate symbol error.

The duplicate symbol error would also be observed if both object files were linked into the executable directly, without first creating a static library.

(This article explains the linker logic very well, I think, and is really worth reading!)

[igrr]

Here's one better: building your sample_project on release/4.4 triggers an infinite loop in the build process.

@KaeLL Zip files contain local modification time, and the archive was created in a timezone which is to the east of you. So when you extract the archive, the modification time of main/CMakeLists.txt is in the future, relative to your local time (even though creation time is the current time). This causes Ninja to re-run CMake. You can verify this (for another hour or so) if you run cmake --build build -- -d explain:

ninja explain: output build.ninja older than most recent input ../main/CMakeLists.txt (1715720472247114987 vs 1715722574000000000)

— this shows the file which causes Ninja to re-run CMake.

I think this issue was fixed in Ninja or in CMake at some point. If you build with ninja >= 1.11, you should not meet this issue.

[KaeLL]

That's a really cool bug. And btw, I'm running ninja 1.11.1