[bug] [clang] Wrong the runtime flag for requirements

[arttet]

If you use -s compiler.runtime=MT or -s compiler.runtime=MTd with Clang on Windows, you will get the error:

lld-link: error: /failifmismatch: mismatch detected for 'RuntimeLibrary':
>>> src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj has value MT_StaticRelease
>>> fmt.lib(format.cc.obj) has value MD_DynamicRelease
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

Environment Details (include every applicable attribute)

• Operating System+version: Windows Server 2019
• Compiler+version: Clang 12.0.0 with GNU-like command-line
• Conan version: 1.39
• Python version: 3.9.6

Steps to reproduce (Include if Applicable)

I have prepared the branch with my changes.

Logs (Executed commands with output) (Include/Attach if Applicable)

lld-link: error: /failifmismatch: mismatch detected for 'RuntimeLibrary':
>>> src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj has value MT_StaticRelease
>>> fmt.lib(format.cc.obj) has value MD_DynamicRelease
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
ERROR: conanfile.py (reproduce-bugs/0.0.0): Error in build() method, line 60
	cmake.build()
	ConanException: Error 1 while executing cmake --build D:\a\reproduce-bugs\reproduce-bugs\build -- -j2

[franramirez688]

Hi @arttet

I'm not able to reproduce the bug. I'm using:

• Windows 10
• Conan 1.40.2
• Clang:

clang version 12.0.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

When I execute your file, this is my output:

Configuration:
[settings]
arch=x86_64
arch_build=x86_64
arch_target=x86_64
build_type=Debug
compiler=Visual Studio
compiler.cppstd=17
compiler.runtime=MTd
compiler.toolset=v142
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

conanfile.py (reproduce-bugs/0.0.0): Installing package
Requirements
Packages

Installing (downloading, building) binaries...
conanfile.py (reproduce-bugs/0.0.0): Generator txt created conanbuildinfo.txt
conanfile.py (reproduce-bugs/0.0.0): Generator cmake created conanbuildinfo.cmake
conanfile.py (reproduce-bugs/0.0.0): Aggregating env generators
conanfile.py (reproduce-bugs/0.0.0): Generated conaninfo.txt
conanfile.py (reproduce-bugs/0.0.0): Generated graphinfo
Using lockfile: 'C:\Users\franc\develop\issues\reproduce-bugs\build/conan.lock'
Using cached profile from lockfile
conanfile.py (reproduce-bugs/0.0.0): Calling build()
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
-- The CXX compiler identification is MSVC 19.29.30133.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan setting CPP STANDARD: 17 WITH EXTENSIONS OFF
-- Conan: Skipping compiler check: Declared 'compiler.toolset'
-- The C compiler identification is MSVC 19.29.30133.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
CMake Warning:
 Manually-specified variables were not used by the project:

   BUILD_SHARED_LIBS
   CMAKE_EXPORT_NO_PACKAGE_REGISTRY
   CMAKE_INSTALL_BINDIR
   CMAKE_INSTALL_DATAROOTDIR
   CMAKE_INSTALL_INCLUDEDIR
   CMAKE_INSTALL_LIBDIR
   CMAKE_INSTALL_LIBEXECDIR
   CMAKE_INSTALL_OLDINCLUDEDIR
   CMAKE_INSTALL_SBINDIR
   CONAN_COMPILER_VERSION


-- Build files have been written to: C:/Users/franc/develop/issues/reproduce-bugs/build
Microsoft (R) Build Engine version 16.11.0+0538acc04 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

 reproduce-bugs.vcxproj -> C:\Users\franc\develop\issues\reproduce-bugs\build\bin\reproduce-bugs.exe

Is the link to reproduce the steps the good one? or am I missing something? Because the command is not using Clang anymore so I think I'm not doing anything else

[arttet]

Hi @franramirez688

Unfortunately, I can reproduce the bug. It seems you need to use another branch such as bug/MD;

[franramirez688]

Yes, it's failing now but the fail is slightly different I guess:

[2/2] Linking CXX executable bin\reproduce-bugs.exe
FAILED: bin/reproduce-bugs.exe
cmd.exe /C "cd . && C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -fuse-ld=lld-link -nostartfiles -nostdlib -m64 -stdlib=libstdc++ -O3 -DNDEBUG  -D_DEBUG -Xclang -flto-visibility-public-std -D_MT -Xclang --dependent-lib=libcmtd -Xlinker /subsystem:console src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj -o bin\reproduce-bugs.exe -Xlinker /implib:lib\reproduce-bugs.lib -Xlinker /pdb:bin\reproduce-bugs.pdb -Xlinker /version:0.0  -LC:/Users/franc/.conan/data/fmt/8.0.1/_/_/package/59086196bdb2b01be060a97bc75878d028684765/lib C:/Users/franc/.conan/data/fmt/8.0.1/_/_/package/59086196bdb2b01be060a97bc75878d028684765/lib/fmt.lib  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames && cd ."
clang++: warning: argument unused during compilation: '-stdlib=libstdc++' [-Wunused-command-line-argument]
lld-link: error: /failifmismatch: mismatch detected for '_ITERATOR_DEBUG_LEVEL':
>>> src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj has value 2
>>> fmt.lib(format.cc.obj) has value 0
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

I think we'll have to look into this issue to see what's going on.

[arttet]

There is another bug related to argument unused during compilation: '-stdlib=libstdc++'

[franramirez688]

Hi @arttet

I was figuring out what was happening and the problem is due to old "cmake" and "cmake_find_package" generators are not passing well the same link flags for both host and build machines so basically the dependency was being built with "Debug" flag and the package with "Release" one. I have opened a PR to your repo so it's basically using the new conan.tools.cmake generators and now building correctly your package.
These kind of problems for legacy generators are quite difficult to solve in a fast way so that's the reason I recommend you to have a look at these new ones. Let me know if you have any other doubt.

[arttet]

Hi @franramirez688

It looks good to me. So, I merged your PR. Could you please give me a couple of days to check other receipts? I'll rewrite my receipts and give feedback about them.

[arttet]

Hi @franramirez688

Unfortunately, there is a case when I cannot build my project. It seems your example uses MD flags. I tried to use ASan with Clang and found the following error:

lld-link: error: /failifmismatch: mismatch detected for 'RuntimeLibrary':
>>> clang_rt.asan_cxx-x86_64.lib(ubsan_type_hash_win.cpp.obj) has value MT_StaticRelease
>>> CMakeFiles/reproduce-bugs.dir/main.cpp.obj has value MD_DynamicRelease

I prepared the branch with this case.
Maybe, I made a mistake when I was rewriting Conanfile.

[franramirez688]

Hi @arttet

As I commented in the PR, that problem was related to the use of Release build type instead of Debug one. It was not a Conan-related issue but flags one. I found out some information here.

Now, the error is another one:

clang++: warning: argument unused during compilation: '-stdlib=libstdc++' [-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: '-stdlib=libstdc++' [-Wunused-command-line-argument]
error: cannot make section .ASAN$GL associative with sectionless symbol ?id@?$numpunct@_W@std@@2V0locale@2@A
error: cannot make section .ASAN$GL associative with sectionless symbol ?id@?$numpunct@D@std@@2V0locale@2@A
2 errors generated.

It seems a problem with the flags or even the main.cpp code used but I cannot ensure it.

[arttet]

Hi @franramirez688

Unfortunately, I do not think so. We should compile with MT or MD (link).
If we compile with Debug and MTd, we'll get the following error:

lld-link: error: /failifmismatch: mismatch detected for '_ITERATOR_DEBUG_LEVEL':
>>> clang_rt.asan_cxx-x86_64.lib(ubsan_type_hash_win.cpp.obj) has value 0
>>> src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj has value 2

It means ASan was built with Release

If we compile with RelWithDebInfo mode and MT, why will we get the following error:

lld-link: error: /failifmismatch: mismatch detected for 'RuntimeLibrary':
>>> clang_rt.asan_cxx-x86_64.lib(ubsan_type_hash_win.cpp.obj) has value MT_StaticRelease
>>> src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj has value MD_DynamicRelease

I cannot realize why main.cpp.obj has value MD_DynamicRelease.

[arttet]

Hi @franramirez688

When I added set(CMAKE_CXX_FLAGS_RELEASE "-MT"), I got the following error:

lld-link: error: /failifmismatch: mismatch detected for 'RuntimeLibrary':
>>> src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj has value MT_StaticRelease
>>> fmt.lib(format.cc.obj) has value MD_DynamicRelease

I think there is a bug related to my new conanfile.py.

[arttet]

Hi @franramirez688

I was figuring out what was happening. The problem is due to avoiding the -MT flag. I added compile_commands.json to CI to confirm it. You can download this file and check it.

[franramirez688]

Oh, very good catch @arttet!

Let me have a look at the Conan code because it could be a bug using Clang + runtime flag then.

[franramirez688]

Hi @arttet

I still have doubts about if Conan is causing the issue.
I have been trying to figure out the problem and I'm not able to get it yet.

If we look at the output:

FAILED: src/reproduce-bugs.exe
cmd.exe /C "cd . && C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -fuse-ld=lld-link -nostartfiles -nostdlib -fsanitize=address   -m64 -O3 -DNDEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -m64  -Xlinker /subsystem:console src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj -o src\reproduce-bugs.exe -Xlinker /implib:src\reproduce-bugs.lib -Xlinker /pdb:src\reproduce-bugs.pdb -Xlinker /version:0.0   C:/Users/franc/.conan/data/fmt/8.0.1/_/_/package/aee07fa1c5c14247e1cf02f8f7125842243ff148/lib/fmt.lib  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames && cd ."
lld-link: error: /failifmismatch: mismatch detected for 'RuntimeLibrary':
>>> clang_rt.asan_cxx-x86_64.lib(ubsan_type_hash_win.cpp.obj) has value MT_StaticRelease
>>> src/CMakeFiles/reproduce-bugs.dir/main.cpp.obj has value MD_DynamicRelease

There are tons of flags that Conan is not including at all, like -DNDEBUG -D_DLL -D_MT ones for instance.
I'm going to try to reproduce the issue with a simpler case.

[franramirez688]

Hi @arttet

I just updated my open PR and it seems to be working now: arttet/reproduce-bugs#3

I was able to dig deeper into the issue (I had to create a minimal test.cpp and make it run without Conan) and, finally, adding a simple -MT to the CXXFLAGS was enough to work around the issue.
I would like to open a new issue about improving the Clang runtime management because it's true that Conan is not doing enough to handle it.

[arttet]

Hi @franramirez688

That workaround looks good. I merged your PR.
If you could keep me in the loop regarding this issue, I would appreciate it.

[franramirez688]

Hi @arttet

I have opened one issue to improve the Clang-runtime-flags management: #9895
I'll keep you posted.

[franramirez688]

Let's close the issue and if anything happens again we can reopen it for sure.

[franramirez688]

Hi @arttet

After a long time, I have been figuring out a bit more about this case because I realized that clang does not manage runtime flags like clang-cl so the question is how did it solve the issue to put -MT -fsanitize=address? the answer is simple, it didn't. Here, we go:

• -MT <arg> -> Specify name of main file output in depfile (doc here): it's not related to runtime at all. Then, we were passing -fsanitize=address as the argument so we were not linking against the ASan library for sure.
• The SOLUTION is to use -fsanitize=address -shared-libsan instead. Now, we're correctly linking with it (doc here).

I thought it was important to share with you the results of this investigation. I have also gathered other interesting links related to this issue:

• Questions on linking with -fsanitize=address google/sanitizers#1086
• https://clang.llvm.org/docs/UsersManual.html#finding-clang-runtime-libraries