CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-11-30T07:58:17-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/17510MSVC as ASM gets confused if Cygwin ld.exe is in the PATH2017-11-30T07:58:17-05:00Mario EmmenlauerMSVC as ASM gets confused if Cygwin ld.exe is in the PATHI have a CI system set up that uses Cygwin for a number of automation tasks. Therefore I have Cygwin's bin/ directory at the end of my PATH system-wide. Now when I use official cmake-3.9.6-win64-x64 from a Visual Studio Build Tools x64 C...I have a CI system set up that uses Cygwin for a number of automation tasks. Therefore I have Cygwin's bin/ directory at the end of my PATH system-wide. Now when I use official cmake-3.9.6-win64-x64 from a Visual Studio Build Tools x64 Command Prompt, cmake will find ``ld.exe`` in the PATH and try to use it instead of ``link.exe``. ``ld.exe`` comes from Cygwin binutils and comes in the PATH after ``link.exe``. I think the latter should be prefered. Is there some way how I can change this behavior wihtout the need to physically remove the file ``ld.exe``?3.11.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18575ASM compiler id not found for Clang with CMake 3.13.0-rc32018-11-12T08:16:32-05:00Gregor JasnyASM compiler id not found for Clang with CMake 3.13.0-rc3Hello,
I noticed that CMake 3.13.0-rc3 has broken support for GNU assembly for Android. CMake 3.12.3 works as expected. Testcase:
Content of `CMakeLists.txt`:
```CMake
cmake_minimum_required(VERSION 3.8 FATAL_ERROR)
project(test...Hello,
I noticed that CMake 3.13.0-rc3 has broken support for GNU assembly for Android. CMake 3.12.3 works as expected. Testcase:
Content of `CMakeLists.txt`:
```CMake
cmake_minimum_required(VERSION 3.8 FATAL_ERROR)
project(testcase)
enable_language(ASM)
add_library(foo STATIC foo.S)
```
Content of `foo.S`
```
.arm
```
Configure with: `cmake -GNinja -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/opt/android-ndk-r16b -DCMAKE_ANDROID_ARCH_ABI=armeabi-v7a -DCMAKE_SYSTEM_VERSION=19 -DCMAKE_ANDROID_STL_TYPE=c++_static -DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang ..`
Resulting compilation line with CMake 3.12: `/opt/android-ndk-r16b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -target armv7-none-linux-androideabi --sysroot=/opt/android-ndk-r16b/sysroot -g -fPIC -MD -MT CMakeFiles/foo.dir/foo.S.o -MF CMakeFiles/foo.dir/foo.S.o.d -o CMakeFiles/foo.dir/foo.S.o -c ../foo.S`
Faulty line with 3.13rc: `/opt/android-ndk-r16b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -o CMakeFiles/foo.dir/foo.S.o -c ../foo.S`
Thanks,
Gregor3.13.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18406Full path to ASM sometimes not correctly determined2018-10-03T13:02:12-04:00Raul LaasnerFull path to ASM sometimes not correctly determinedAs an example, consider the following input:
```
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
project(test LANGUAGES Fortran)
enable_language(ASM)
add_executable(main main.f90)
# main.f90
end
```
Configuring with `-DCMAKE_C_COM...As an example, consider the following input:
```
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
project(test LANGUAGES Fortran)
enable_language(ASM)
add_executable(main main.f90)
# main.f90
end
```
Configuring with `-DCMAKE_C_COMPILER=gcc` results in
```
-- The Fortran compiler identification is GNU 8.2.1
-- Check for working Fortran compiler: /bin/f95
-- Check for working Fortran compiler: /bin/f95 -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /bin/f95 supports Fortran 90
-- Checking whether /bin/f95 supports Fortran 90 -- yes
-- The ASM compiler identification is GNU
-- Found assembler: gcc
CMake Error at CMakeLists.txt:8 (enable_language):
The CMAKE_ASM_COMPILER:
gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "ASM" or the CMake cache entry CMAKE_ASM_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
```
even though `gcc` is in the PATH. I'm opening this issue following !2418.3.13.0https://gitlab.kitware.com/cmake/cmake/-/issues/20236MSVC_RUNTIME_LIBRARY Incompatible with ASM_MASM project2020-02-04T10:41:23-05:00Jonny PatonMSVC_RUNTIME_LIBRARY Incompatible with ASM_MASM projectIf a project contains asm code compiled using ASM_MASM along with cpp code, and you enable policy CMP0091 to modify the MSVC runtime library, the following error occurs:
```
MSVC_RUNTIME_LIBRARY value 'MultiThreadedDebugDLL' not known...If a project contains asm code compiled using ASM_MASM along with cpp code, and you enable policy CMP0091 to modify the MSVC runtime library, the following error occurs:
```
MSVC_RUNTIME_LIBRARY value 'MultiThreadedDebugDLL' not known for this
ASM_MASM compiler.
```
Using Visual studio 2019 (16.4.3) and cmake 3.16.0.
Can be reproduced using a simple CMakeLists like so:
```
cmake_minimum_required(VERSION 3.10)
cmake_policy(SET CMP0091 NEW)
project(test C CXX ASM_MASM)
add_library(test_lib test.asm test.cpp)
```3.15.7Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20780GNU: Incorrect defines flag for 'as' tool2020-06-02T06:39:52-04:00Brad KingGNU: Incorrect defines flag for 'as' toolOur `RunCMake.BuildDepends` test (in `master`) fails with the Ninja Multi-Config generator when testing with the GNU compiler, which activates the `CMake_TEST_BuildDepends_GNU_AS` part of the test.
See further discussion in https://gitl...Our `RunCMake.BuildDepends` test (in `master`) fails with the Ninja Multi-Config generator when testing with the GNU compiler, which activates the `CMake_TEST_BuildDepends_GNU_AS` part of the test.
See further discussion in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4832#note_769837.3.18.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/20771CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES don't work for assembly2020-12-04T09:07:12-05:00David BenjaminCMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES don't work for assemblyThe `CMAKE_OSX_SYSROOT` and `CMAKE_OSX_ARCHITECTURES` settings aren't propagated to assembly files, like they are for C and C++, when building for Apple platforms. Here's a small repro case:
```
$ cat CMakeLists.txt
cmake_minimum_requi...The `CMAKE_OSX_SYSROOT` and `CMAKE_OSX_ARCHITECTURES` settings aren't propagated to assembly files, like they are for C and C++, when building for Apple platforms. Here's a small repro case:
```
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.17)
project(test)
enable_language(ASM)
if(WORKAROUND)
if(CMAKE_OSX_SYSROOT)
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -isysroot \"${CMAKE_OSX_SYSROOT}\"")
endif()
foreach(arch ${CMAKE_OSX_ARCHITECTURES})
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -arch ${arch}")
endforeach()
endif()
add_executable(test main.c return_zero.S)
$ cat main.c
extern int return_zero(void);
int main() {
return return_zero();
}
$ cat return_zero.S
.text
.align 5
.globl _return_zero
_return_zero:
mov x0, 0
ret
$ cmake -B build1 -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64 && make -C build1
[...]
[ 66%] Building ASM object CMakeFiles/test.dir/return_zero.S.o
[...]/return_zero.S:6:2: error: unknown use of instruction mnemonic without a size suffix
mov x0, 0
^
[...]
$ cmake -B build2 -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64 -DWORKAROUND=1 && make -C build2
[...]
[100%] Built target test
```3.19.0https://gitlab.kitware.com/cmake/cmake/-/issues/21553ASM_NASM: CMake 3.19.1 adds unsupported '-arch x86_64' on macOS2020-12-07T10:28:25-05:00fpliuASM_NASM: CMake 3.19.1 adds unsupported '-arch x86_64' on macOS[https://github.com/libjpeg-turbo/libjpeg-turbo/issues/473](https://github.com/libjpeg-turbo/libjpeg-turbo/issues/473)[https://github.com/libjpeg-turbo/libjpeg-turbo/issues/473](https://github.com/libjpeg-turbo/libjpeg-turbo/issues/473)3.19.2Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22341CMake 3.21.0-rc1 broke YASM support2021-06-28T09:19:12-04:00Gregor JasnyCMake 3.21.0-rc1 broke YASM supportThe [nasm_add_deps topic](!5868) introduced generation of GCC-compatible depfiles by the NASM assembler. Unfortunately it closed the door for YASM assembler support because yasm does not support the `-MD` and `-MT` arguments.
The follow...The [nasm_add_deps topic](!5868) introduced generation of GCC-compatible depfiles by the NASM assembler. Unfortunately it closed the door for YASM assembler support because yasm does not support the `-MD` and `-MT` arguments.
The following testcase reproduces the problem:
```cmake
cmake_minimum_required(VERSION 3.20 FATAL_ERROR)
project(testcase NONE)
find_program(NASM_EXECUTABLE yasm)
set(CMAKE_ASM_NASM_COMPILER ${NASM_EXECUTABLE})
enable_language(ASM_NASM)
add_library(foo foo.asm)
```
Building results in an error:
```
ninja -v
[1/2] /opt/homebrew/bin/yasm -MD CMakeFiles/foo.dir/foo.asm.o.d -MT CMakeFiles/foo.dir/foo.asm.o -f macho -o CMakeFiles/foo.dir/foo.asm.o /Users/gregorj/src/cmake-issue-yarn/foo.asm
yasm: warning: can open only one input file, only the last file will be processed
yasm: warning: can open only one input file, only the last file will be processed
CMakeFiles/foo.dir/foo.asm.o: /Users/gregorj/src/cmake-issue-yarn/foo.asm
[2/2] : && /usr/bin/ar cr libfoo.a CMakeFiles/foo.dir/foo.asm.o && /usr/bin/ranlib libfoo.a && :
FAILED: libfoo.a
: && /usr/bin/ar cr libfoo.a CMakeFiles/foo.dir/foo.asm.o && /usr/bin/ranlib libfoo.a && :
ar: CMakeFiles/foo.dir/foo.asm.o: No such file or directory
ninja: build stopped: subcommand failed.
```
Thanks,
Gregor3.21.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/24249ASM_MASM: Missing support for MSVC_DEBUG_INFORMATION_FORMAT2022-12-16T08:55:27-05:00stl@microsoft.comASM_MASM: Missing support for MSVC_DEBUG_INFORMATION_FORMATRepros with CMake 3.25.0 shipping in VS 2022 17.5 Preview 2.
In our project ([MSVC's STL](https://github.com/microsoft/STL)), we have ASM_MASM sources. When I tried to increase our minimum required version of CMake, it failed with:
```...Repros with CMake 3.25.0 shipping in VS 2022 17.5 Preview 2.
In our project ([MSVC's STL](https://github.com/microsoft/STL)), we have ASM_MASM sources. When I tried to increase our minimum required version of CMake, it failed with:
```
CMake Error in CMakeLists.txt:
MSVC_DEBUG_INFORMATION_FORMAT value 'ProgramDatabase' not known for this
ASM_MASM compiler.
```
This is related to this new feature mentioned in the [CMake 3.25 release notes](https://cmake.org/cmake/help/latest/release/3.25.html):
> The [`CMAKE_MSVC_DEBUG_INFORMATION_FORMAT`](https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_DEBUG_INFORMATION_FORMAT.html#variable:CMAKE_MSVC_DEBUG_INFORMATION_FORMAT) variable and [`MSVC_DEBUG_INFORMATION_FORMAT`](https://cmake.org/cmake/help/latest/prop_tgt/MSVC_DEBUG_INFORMATION_FORMAT.html#prop_tgt:MSVC_DEBUG_INFORMATION_FORMAT) target property were introduced to select the debug information format for compilers targeting the MSVC ABI. See policy [`CMP0141`](https://cmake.org/cmake/help/latest/policy/CMP0141.html#policy:CMP0141).
As the example below demonstrates, we can work around this by setting the `CMP0141` policy to `OLD`. However, I believe that this workaround should not be necessary, and that this is a bug in CMake - it appears that its internal machinery wasn't taught how to send debug info options to MASM.
While I am not a MASM expert, [MASM documentation](https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) says that `/Zi` "Generates CodeView information in object file.", and comments in MSVC's STL note that (somewhat confusingly) this is equivalent to what `/Z7` does for the `cl.exe` compiler - so `Embedded` in CMake's terminology should be translated to `/Zi` for MASM.
As linked from the release notes, CMake's documentation for [`CMAKE_MSVC_DEBUG_INFORMATION_FORMAT`](https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_DEBUG_INFORMATION_FORMAT.html#variable:CMAKE_MSVC_DEBUG_INFORMATION_FORMAT) says:
> If this variable is not set, the `MSVC_DEBUG_INFORMATION_FORMAT` target property will not be set automatically. If that property is not set, CMake selects a debug information format using the default value `$<$<CONFIG:Debug,RelWithDebInfo>:ProgramDatabase>`, if supported by the compiler, and otherwise `$<$<CONFIG:Debug,RelWithDebInfo>:Embedded>`.
If I understand this correctly, because MASM doesn't support `ProgramDatabase`, CMake should fall back to `Embedded` instead of emitting an error that it doesn't know what to do.
```
C:\Temp\REPRO>"C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Auxiliary\Build\vcvars64.bat"
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.5.0-pre.2.0
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
C:\Temp\REPRO>cmake --version
cmake version 3.25.0-msvc1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
C:\Temp\REPRO>type CMakeLists.txt
```
```cmake
cmake_minimum_required(VERSION 3.25)
if(DEFINED OVERRIDE_CMP0141)
cmake_policy(SET CMP0141 ${OVERRIDE_CMP0141})
endif()
project(meow_project LANGUAGES CXX ASM_MASM)
set(SOURCES
${CMAKE_CURRENT_LIST_DIR}/meow.cpp
${CMAKE_CURRENT_LIST_DIR}/square.asm
)
add_executable(meow ${SOURCES})
```
```
C:\Temp\REPRO>type meow.cpp
```
```cpp
#include <cstdio>
extern "C" int square(int x);
int main() {
std::printf("\nHello, CMake world!\n");
std::printf("square(7): %d\n", square(7));
}
```
```
C:\Temp\REPRO>type square.asm
PUBLIC square
_TEXT SEGMENT
square PROC
imul ecx, ecx
mov eax, ecx
ret 0
square ENDP
_TEXT ENDS
END
C:\Temp\REPRO>cmake -G Ninja -S . -B out && ninja -C out && out\meow.exe
-- The CXX compiler identification is MSVC 19.35.32124.0
-- The ASM_MASM compiler identification is MSVC
-- Found assembler: C:/Program Files/Microsoft Visual Studio/2022/Preview/VC/Tools/MSVC/14.35.32124/bin/Hostx64/x64/ml64.exe
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Preview/VC/Tools/MSVC/14.35.32124/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
CMake Error in CMakeLists.txt:
MSVC_DEBUG_INFORMATION_FORMAT value 'ProgramDatabase' not known for this
ASM_MASM compiler.
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
C:\Temp\REPRO>cmake -G Ninja -S . -B out -DOVERRIDE_CMP0141=OLD && ninja -C out && out\meow.exe
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Temp/REPRO/out
ninja: Entering directory `out'
[1/3] Building ASM_MASM object CMakeFiles\meow.dir\square.asm.obj
Microsoft (R) Macro Assembler (x64) Version 14.35.32124.0
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: C:\Temp\REPRO\square.asm
[3/3] Linking CXX executable meow.exe
Hello, CMake world!
square(7): 49
```
Note: This seems to be similar to an old issue https://gitlab.kitware.com/cmake/cmake/-/issues/19453 but it is definitely not a duplicate of that issue.3.25.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24304ASM_MARMASM: The CMAKE_ASM_MARMASM_FLAGS are not getting inside the .asm2023-02-13T11:46:29-05:00Randeep KumarASM_MARMASM: The CMAKE_ASM_MARMASM_FLAGS are not getting inside the .asmHi Team,
The CMAKE_ASM_FLAGS are not getting inside the .asm files when compiled using armasm.
I'm trying this using the nightly build in which the .asm compilation is fixed for the armasm assembler. (#24134)
The new issue I'm facing is ...Hi Team,
The CMAKE_ASM_FLAGS are not getting inside the .asm files when compiled using armasm.
I'm trying this using the nightly build in which the .asm compilation is fixed for the armasm assembler. (#24134)
The new issue I'm facing is the CMAKE_ASM_FLAGS are not getting inside the .asm files. Does this need to be fixed in the CMake source code?3.26.0https://gitlab.kitware.com/cmake/cmake/-/issues/24289VS: ASM_MASM not adding target_compile_options() to the ml.exe command2024-01-09T12:00:56-05:00dr vengyVS: ASM_MASM not adding target_compile_options() to the ml.exe commandRan into this issue from [StackOverflow](https://stackoverflow.com/questions/75024972/cmake-asm-masm-language-not-adding-target-compile-options-to-the-masm-ml-exe-c)
when trying to assemble a MASM project using cmake version 3.24.3, the ...Ran into this issue from [StackOverflow](https://stackoverflow.com/questions/75024972/cmake-asm-masm-language-not-adding-target-compile-options-to-the-masm-ml-exe-c)
when trying to assemble a MASM project using cmake version 3.24.3, the `target_compile_options()` below
```
if(WIN32)
target_compile_options(HelloWorld
PUBLIC
/DBUILD_HelloWorld
/FlHelloWorld.lst
)
target_link_options(HelloWorld
PUBLIC
/SUBSYSTEM:Console,6.01
/SAFESEH:NO
)
...
```
are not added to the MASM command
` [Build:x86] ml.exe /c /nologo /Zi /Fo"HelloWorld.dir\Debug\CodeBaseEND.obj" /D"CMAKE_INTDIR="Debug"" ...`
However, during the linking phase, the `target_link_options()` are added
` [Build:x86] C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30133\bin\HostX64\x86\link.exe /ERRORREPORT:QUEUE ... /SAFESEH:NO /SUBSYSTEM:Console,6.01`
The root `CMakeLists.txt` file has these languages defined
project(HelloWorld VERSION 1.0.0 LANGUAGES C CXX ASM_MASM)
**Any ideas why the compile options are omitted or where the fix might be?**
Thanks.3.26.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24134The asm files are not getting compiled when CMAKE_ASM_COMPILER is set to armasm2023-01-10T06:51:24-05:00Randeep KumarThe asm files are not getting compiled when CMAKE_ASM_COMPILER is set to armasmDoes CMake supports armasm compiler? The asm files are not getting compiled when CMAKE_ASM_COMPILER is set to armasm.Does CMake supports armasm compiler? The asm files are not getting compiled when CMAKE_ASM_COMPILER is set to armasm.3.26.0https://gitlab.kitware.com/cmake/cmake/-/issues/24984Ninja/ASM/Apple: Fat library fails to rebuild after assembly source file is u...2023-06-08T11:03:51-04:00Thomas A.Ninja/ASM/Apple: Fat library fails to rebuild after assembly source file is updated<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
# Issue
When ninja tries to build a fat library that contains an assembly source, it will fail to build on a consecutive run when the assembly source has been updated.
```
[2/2] : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cr libdylib1_10_5.a CMakeFiles/dylib1_10_5.dir/dyld_glue.S.o && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib libdylib1_10_5.a && :
FAILED: libdylib1_10_5.a
: && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cr libdylib1_10_5.a CMakeFiles/dylib1_10_5.dir/dyld_glue.S.o && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib libdylib1_10_5.a && :
ar: libdylib1_10_5.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: libdylib1_10_5.a: Inappropriate file type or format
ninja: build stopped: subcommand failed.
```
From my testing, the following two conditions need to be met for this bug to occur:
* the object built must be universal binary (ex: `set(CMAKE_OSX_ARCHITECTURES "i386;x86_64")`).
* The source file needs to be an assembly file.
This issue does not occur when using `make`. This has been tested on macOS (this issue can also happen on Linux when cross-building macOS executables).
# How to reproduce
1. Clone `https://github.com/apple-oss-distributions/Csu.git`. Checkout `Csu-88`.
2. Add the following `CMakeLists.txt` file & rename `dyld_glue.s` to `dyld_glue.S`:
```cmake
cmake_minimum_required(VERSION 3.24.2)
project(csu)
enable_language(ASM)
set(CMAKE_OSX_ARCHITECTURES "i386;x86_64")
ADD_LIBRARY(dylib1_10_5 STATIC dyld_glue.S)
target_compile_options(dylib1_10_5
PRIVATE
-r
-Os
-mmacosx-version-min=10.5
-nostdlib
-keep_private_externs
-DCFM_GLUE
)
```
3. Create a `build` folder and build the library as you normally would:
```
mkdir build
cd build
cmake .. -GNinja
ninja -v
```
4. Use `touch` to simulate file being updated and do another `ninja` build:
```
touch ../dyld_glue.S
ninja -v
```
5. You should get a build failure.
# Version details
```
% sw_vers
ProductName: macOS
ProductVersion: 13.4
BuildVersion: 22F66
% cmake --version
cmake version 3.26.4
CMake suite maintained and supported by Kitware (kitware.com/cmake).
```https://gitlab.kitware.com/cmake/cmake/-/issues/24797VS: The MASM change added in 3.26.x breaks VS ARM64 build2023-04-26T15:28:50-04:00Changming SunVS: The MASM change added in 3.26.x breaks VS ARM64 buildYou can get a reproducible example from https://gitlab.kitware.com/cmake/cmake/-/issues/21462 . Try it on a Windows ARM64 machine with Visual Studio 2022 ARM64 version. To get VS 2022 ARM64 version, just install it normally. The ARM64 ve...You can get a reproducible example from https://gitlab.kitware.com/cmake/cmake/-/issues/21462 . Try it on a Windows ARM64 machine with Visual Studio 2022 ARM64 version. To get VS 2022 ARM64 version, just install it normally. The ARM64 version and x86 version share the same installer. Then build the sample. cmake 3.25.x works fine, while cmake 3.26.x does not. Error message with cmake 3.26:
```
2>C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\BuildCustomizations\masm.targets(70,5): error MSB3721: The command "echo MASM not supported on this platform
```
I also submitted an issue to VS: https://developercommunity.visualstudio.com/t/Does-Visual-Studio-Windows-ARM64-version/10331301?viewtype=all . I'm not sure it is a limitation of cmake or VS, but definitely this is a breaking change for cmake.https://gitlab.kitware.com/cmake/cmake/-/issues/24317ASM_MARMASM: Support for compile definitions and options2024-03-10T12:16:50-04:00Brad KingASM_MARMASM: Support for compile definitions and options!7793 added support for the `ASM_MARMASM` language, for #23999.
However, there are some features missing:
* `target_compile_definitions`
* With Ninja, ~~the definitions are added with `-D`~~ (EDIT: Removed by !9326), which is not ...!7793 added support for the `ASM_MARMASM` language, for #23999.
However, there are some features missing:
* `target_compile_definitions`
* With Ninja, ~~the definitions are added with `-D`~~ (EDIT: Removed by !9326), which is not a valid flag for the `armasm64` tool.
* With Visual Studio, the definitions are put in the `.vcxproj` file, but they do not appear on the `armasm64` command line.
* `target_compile_options`
* With Ninja, the compile options are added.
* ~~With Visual Studio, the compile options are not placed in the `.vcxproj` file, similar to #24289 for MASM.~~ EDIT: This was fixed by !8125.https://gitlab.kitware.com/cmake/cmake/-/issues/24078VS/NASM: Same source filename outputs to same OBJ file and directory2022-10-24T14:34:50-04:00Mir DrualgaVS/NASM: Same source filename outputs to same OBJ file and directoryUsing CMake 3.24.2 and NASM 2.15.05. Running Windows 10 Pro 21H2 19044.2130. Attempted to build using "Visual Studio 2019 Community" generator targeting x86.
Target contains C, CXX, and NASM files. C and CXX source files with the same f...Using CMake 3.24.2 and NASM 2.15.05. Running Windows 10 Pro 21H2 19044.2130. Attempted to build using "Visual Studio 2019 Community" generator targeting x86.
Target contains C, CXX, and NASM files. C and CXX source files with the same filename, but different parent directories are able to successfully build into different intermediate object file directories. There is no problem there. However, NASM files that share same filename, but different parent directories do not build into different intermediate object directories, and end up overriding each other. This causes the linker to fail due to missing function definitions.
Example:
```
project
|- foo
|- a.c
|- b.asm
|- bar
|- a.c
|- b.asm
```
In this example, foo/a.c and bar/a.c compile to obj files to different directories. However, foo/b.asm and bar/b.asm compile to obj files in the same directory.https://gitlab.kitware.com/cmake/cmake/-/issues/23537MSVC assembler shows "Assembling" messages that should be suppressed2023-02-10T10:49:55-05:00stl@microsoft.comMSVC assembler shows "Assembling" messages that should be suppressedAfter adding an `.asm` file to our repo, the build output is interrupted by "Assembling" messages being printed by MSVC's assembler (`ml64.exe` for x64, `ml.exe` for x86). We're passing `/nologo` to suppress the copyright banner, but tha...After adding an `.asm` file to our repo, the build output is interrupted by "Assembling" messages being printed by MSVC's assembler (`ml64.exe` for x64, `ml.exe` for x86). We're passing `/nologo` to suppress the copyright banner, but that doesn't suppress this message. Example:
```
D:\GitHub\STL>cmake -G Ninja -S . -B out\build\x64
-- The CXX compiler identification is MSVC 19.33.31424.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Preview/VC/Tools/MSVC/14.33.31424/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM_MASM compiler identification is MSVC
-- Found assembler: C:/Program Files/Microsoft Visual Studio/2022/Preview/VC/Tools/MSVC/14.33.31424/bin/Hostx64/x64/ml64.exe
-- Searching for VS clang-format
-- Searching for VS clang-format - found
-- Boost.Math: standalone mode ON
-- Found Python: C:/Users/stl/AppData/Local/Programs/Python/Python310/python.exe (found suitable version "3.10.4", minimum required is "3.9") found components: Interpreter
-- Configuring done
-- Generating done
-- Build files have been written to: D:/GitHub/STL/out/build/x64
D:\GitHub\STL>ninja -C out\build\x64
ninja: Entering directory `out\build\x64'
[108/984] Building ASM_MASM object stl\CMakeFiles\msvcp_implib_objects.dir\src\alias.asm.obj
Assembling: D:\GitHub\STL\stl\src\alias.asm
[244/984] Building ASM_MASM object stl\CMakeFiles\msvcpd_implib_objects.dir\src\alias.asm.obj
Assembling: D:\GitHub\STL\stl\src\alias.asm
[260/984] Building ASM_MASM object stl\CMakeFiles\libcpmt.dir\src\alias.asm.obj
Assembling: D:\GitHub\STL\stl\src\alias.asm
[404/984] Building ASM_MASM object stl\CMakeFiles\libcpmt1.dir\src\alias.asm.obj
Assembling: D:\GitHub\STL\stl\src\alias.asm
[541/984] Building ASM_MASM object stl\CMakeFiles\libcpmtd.dir\src\alias.asm.obj
Assembling: D:\GitHub\STL\stl\src\alias.asm
[682/984] Building ASM_MASM object stl\CMakeFiles\libcpmtd1.dir\src\alias.asm.obj
Assembling: D:\GitHub\STL\stl\src\alias.asm
[828/984] Building ASM_MASM object stl\CMakeFiles\libcpmtd0.dir\src\alias.asm.obj
Assembling: D:\GitHub\STL\stl\src\alias.asm
[984/984] Linking CXX static library out\lib\amd64\libcpmtd0.lib
```
This is similar to https://gitlab.kitware.com/cmake/cmake/-/issues/21422 which was fixed by https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5492 . Could CMake be enhanced to suppress this message when invoking the assembler?https://gitlab.kitware.com/cmake/cmake/-/issues/22995CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN set incorrectly with Clang2021-12-10T09:33:38-05:00Ryan PrichardCMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN set incorrectly with ClangThe `CMAKE_${LANG}_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN` flags are set to `--gcc-toolchain=` for current versions of Clang and `-gcc-toolchain ` for versions older than Clang 3.4.0.
Clang doesn't have an program with a GAS-like CLI syntax...The `CMAKE_${LANG}_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN` flags are set to `--gcc-toolchain=` for current versions of Clang and `-gcc-toolchain ` for versions older than Clang 3.4.0.
Clang doesn't have an program with a GAS-like CLI syntax and instead reuses the C/C++ compiler driver to assemble files.
When CMake uses Clang to assemble, it sets `CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN` to `-gcc-toolchain ` regardless of the Clang version. This is a problem because new versions of Clang removed support for `-gcc-toolchain ` in favor of `--gcc-toolchain=`. https://llvm.org/D108494
`CMAKE_ASM_COMPILER_VERSION` is left blank rather than set to match the C/C++ variables.
A test case:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.21.0)
project(test C CXX ASM)
message(STATUS "CMAKE_ASM_COMPILER_VERSION = ${CMAKE_ASM_COMPILER_VERSION}")
message(STATUS "CMAKE_C_COMPILER_VERSION = ${CMAKE_C_COMPILER_VERSION}")
message(STATUS "CMAKE_CXX_COMPILER_VERSION = ${CMAKE_CXX_COMPILER_VERSION}")
message(STATUS "CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = ${CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_C_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = ${CMAKE_C_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_ASM_COMPILER_EXTERNAL_TOOLCHAIN = ${CMAKE_ASM_COMPILER_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN = ${CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN}")
message(STATUS "CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN = ${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}")
```
Output:
```
$ CC=clang CXX=clang++ cmake -GNinja .
-- The C compiler identification is Clang 11.1.0
-- The CXX compiler identification is Clang 11.1.0
-- The ASM compiler identification is Clang
-- Found assembler: /usr/bin/clang
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_ASM_COMPILER_VERSION =
-- CMAKE_C_COMPILER_VERSION = 11.1.0
-- CMAKE_CXX_COMPILER_VERSION = 11.1.0
-- CMAKE_ASM_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = -gcc-toolchain
-- CMAKE_C_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = --gcc-toolchain=
-- CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN = --gcc-toolchain=
-- CMAKE_ASM_COMPILER_EXTERNAL_TOOLCHAIN =
-- CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN =
-- CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN =
-- Configuring done
-- Generating done
-- Build files have been written to: /x/mess/A
```
I'm using CMake from the cmake-3.21.4-1 debian package. I've also noticed it with a local build of CMake 3.22.1.
This issue currently breaks Android's "legacy toolchain file" (as opposed to its newer toolchain file). The legacy file happens to set the `CMAKE_{ASM,C,CXX}_COMPILER_EXTERNAL_TOOLCHAIN` variables, so it's hitting this general CMake+Clang issue. I don't know if this toolchain file needs to set those variables, so maybe removing that setting is an easy fix in future NDK releases.
References:
* https://github.com/android/ndk/issues/1623
* https://android.googlesource.com/platform/ndk/+/refs/tags/ndk-r24-beta1/build/cmake/android-legacy.toolchain.cmake#404
* https://gitlab.kitware.com/cmake/cmake/-/blob/v3.22.1/Modules/Compiler/Clang.cmake#L37-43https://gitlab.kitware.com/cmake/cmake/-/issues/22817Bug asm in lib on windows with ninja2024-03-06T11:16:26-05:00Andry _Bug asm in lib on windows with ninjaCMAKE_VERSION=3.20.2
ninja --version 1.10.2
I ran into a problem - if I want to create a library based on an asm file for Windows under ninja.
```
add_library(asm_lib file.asm)
```
I get this error
```
FAILED: asm_lib.lib
cmd.exe /C ...CMAKE_VERSION=3.20.2
ninja --version 1.10.2
I ran into a problem - if I want to create a library based on an asm file for Windows under ninja.
```
add_library(asm_lib file.asm)
```
I get this error
```
FAILED: asm_lib.lib
cmd.exe /C "cd . && C:\PROGRA~2\MICROS~2\2019\COMMUN~1\VC\Tools\MSVC\1429~1.300\bin\Hostx64\x64\lib.exe cr asm_lib.lib /machine:x64 CMakeFiles\____file.asm.obj && cd ."
Microsoft (R) Library Manager Version 14.29.30040.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : fatal error LNK1181: cannot open input file 'cr'
```
as far as I understand, 'cr' is a flag and it is for bin/ar under Linux and not for a lib under Windowshttps://gitlab.kitware.com/cmake/cmake/-/issues/21877ASM_NASM: Incorrect command line argument style when using MSVC2021-03-04T12:09:17-05:00Francesco BertolacciniASM_NASM: Incorrect command line argument style when using MSVCOn Windows using MSVC, a simple project such as this one:
```
cmake_minimum_required(VERSION 3.16.0)
project(test VERSION 1.0.0 LANGUAGES C CXX ASM_NASM)
add_library(test STATIC test.asm)
```
fails to link because during the linking ...On Windows using MSVC, a simple project such as this one:
```
cmake_minimum_required(VERSION 3.16.0)
project(test VERSION 1.0.0 LANGUAGES C CXX ASM_NASM)
add_library(test STATIC test.asm)
```
fails to link because during the linking step `link.exe` is called with GNU-style arguments (e.g. `link` complains about not being able to find `cr`)
Additionally, when not specifying `C` or `CXX` languages, building using Ninja fails because no linker is found.