Hi xp,

your build failure is

1. the result of a “link-all” mechanism

or

       2. the result of a library construction flaw that is commonly used in EDK2.

or both

Let me explain the theory:

1. an .OBJ file is created by the compiler for each .C source code file

an .OBJ is considered as atomic, it can not be split into smaller pieces (except with newer compiler switches)

2. a “library“ .LIB is a collection of one or more of such .OBJ files
3. if an .OBJ is passed to linker, it is _always_ linked into the target.EFI

(the linker creates an link-error, like yours, if that particular symbol-name is already present in the target.EFI)

One definition rule: https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk2005?view=msvc-170

4. if an .LIB is passed to the linker instead, the linker searches the .LIB for a particular

symbol (e.g. function, data). The specific .OBJ module that holds that particular symbol, is

linked to the target.EFI.

(the linker creates an link-error, like yours, if that particular symbol-name is already present in the target.EFI)

One definition rule: https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk2005?view=msvc-170

5. to prevent such error each .OBJ of a library can hold only one single symbol, one function or one data.

Only in that case the linker is able to pickup each single symbol from the library and bind it into the target.EFI

without any conflict.

This is also explained here:

https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-12-19#redfishcrtlib-conflicts-with-cdepkg-by-design

Best regards,

Kilian