Multiple definition of '_imp__InterlockedCompareExchange@12'

[ancwrd1]

I am getting a 'multiple definition' link error for the i686-pc-windows-gnu target. Application uses rusqlite crate and winapi crate. The rusqlite crate compiles a native sqlite code (which contains InterlockedCompareExchange references).

The exact error message is:

  = note: /build/.cargo/registry/src/github.com-1ecc6299db9ec823/winapi-i686-pc-windows-gnu-0.4.0/lib/libwinapi_kernel32.a(dgxabs00740.o):(.idata$5+0x0): multiple definition of `_imp__InterlockedCompareExchange@12'
          /usr/lib/gcc/i686-w64-mingw32/7.3-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a(libkernel32s00755.o):(.idata$5+0x0): first defined here
          collect2: error: ld returned 1 exit status                                                                         

Is that an expected behaviour? I found out that this can be avoided by defining WINAPI_NO_BUNDLED_LIBRARIES environment variable but not sure what side effects it might cause. It's also not very convenient to rely on a particular env variable to build a project.

[retep998]

It seems really weird that it is complaining about multiple definitions. Normally the linker should just pick one of the available options depending on library order. Symbols are duplicated all the time between the bundled libraries and the import libraries provided by MinGW and there's never been any reported issues before. Sqlite must be doing something weird about how it links to InterlockedCompareExchange to cause that issue.

Since you have a full MinGW installation, defining WINAPI_NO_BUNDLED_LIBRARIES is the correct workaround for this problem. While it may be inconvenient, I can not change the default, because people use the pc-windows-gnu toolchain all the time without a full MinGW installation and the bundled import libraries are necessary in that case.

[ancwrd1]

How about adding a cargo build feature which does the same as the environment variable?
For example "no-bundled-libraries". Would it be possible?
Then it can be added in Cargo.toml instead of relying on setting the additional build requirements.

[retep998]

Whether to use the bundled libraries depends on whether the user has a full MinGW toolchain installed, and as such is a property of the build environment. Cargo features are not designed to describe the build environment but rather what optional APIs a crate requires from its dependencies.

[ancwrd1]

Ok that makes sense. I am using cross build environment (Linux host, i686-pc-windows-gnu target). I guess for cross builds using WINAPI_NO_BUNDLED_LIBRARIES is essential because full MinGW toolchain is needed for linking.

[ancwrd1]

Just for the reference, can be also resolved with linker flag: -Wl,--allow-multiple-definition

I think this issue can be closed.

[retep998]

Allowing multiple definitions is the default for symbols being pulled from libraries, which is why this is so weird. I'd still like it if someone could investigate exactly why multiple definitions aren't being allowed in this one specific case just so I can have some closure.