Minimum CMake downgrade for Linux

[jkoritzinsky]

Downgrade the minimum version of CMake to 3.6.2 for our Linux builds and change our CMake scripts appropriately:

Currently completed steps:

• Provide our own implementation of add_compile_definitions since it is easily polyfillable
• Move away from add_link_options since it is not easy to create our own implementation of that functions the same. Move back to setting linker options via the flag properties.
• Manually enable PIE/PIC on Linux/Mac (this support was added in CMake 3.9)
• Manually check for IPO support on Linux/Mac (this support was added in CMake 3.13)
• Revert to the old CMake command line (this support was added in CMake 3.10)

So far I've only undone the changes that I made in dotnet/coreclr#26980 that I know are required. @janvorli can you help out with some of the other issues that we'll encounter when lowering the CMake version? I don't know all of the corner case behaviors that we've started to depend on in the last 10ish months.

Validation that we actually build on CMake 3.6.2 will come when we get a new Docker image has CMake 3.6.2 (and no newer) installed (@jashook is working on this).

Contributes to #38755

Depends on dotnet/arcade#5770

cc: @dleeapho@janvorli@jashook@omajid@jkotas@tmds@wfurt@RheaAyase

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[omajid]

Thanks for this PR!

I tried building ad16a9797a2e899caec8a610f667789e0bec6524 using ./build.sh on RHEL 8. It doesn't seem to work. This is cmake version 3.11.4

 Detected Linux x86_64 -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG - Success -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/clang CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/static/CMakeLists.txt:41 (include) -- Performing Test HAVE_DIRENT_D_TYPE -- Performing Test HAVE_DIRENT_D_TYPE - Success Looking for coreclr_static lib at location: '/home/dotnet/runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib'. CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/standalone/CMakeLists.txt:39 (include) CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/dotnet/CMakeLists.txt:16 (include) CMake Error at cli/fxr/standalone/CMakeLists.txt:51 (target_link_libraries): Target "libhostfxr_static" of type OBJECT_LIBRARY may not be linked into another target. One may link only to INTERFACE, STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. CMake Error at cli/test/mockhostfxr/CMakeLists.txt:4 (cmake_minimum_required): CMake 3.14.5 or higher is required. You are running version 3.11.4 -- Configuring incomplete, errors occurred!

Please let me know if there's anything I can do to help.

[jkoritzinsky]

I've fixed the issues that I've found relatively simple (removing the unknown policy and removing the extra cmake_minimum_required), but I'm not sure how to fix the libhostfxr_static linking issue. If you know how to downgrade that, I'd appreciate the help.

[omajid]

If you know how to downgrade that, I'd appreciate the help.

Not off the top of my head. I will dig around.

[janvorli]

but I'm not sure how to fix the libhostfxr_static linking issue

The object libraries cannot be used as regular libraries to link to prior to cmake 3.14. All places need to be changed so that the objects from the object libraries are added to the respective targets like source files. E.g.:

add_library(... $<TARGET_OBJECTS:objlib> ...)

[jashook]

I am having trouble building with 3.6.2. Seems that https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/eventing/CMakeLists.txt#L11 requires cmake 3.8+.

How did you get around this @jkoritzinsky

[jkoritzinsky]

I forgot about that. I need to roll that back to use the old find python module.

[jkoritzinsky]

@safern can you take a look at the libraries build failures on OSX?

[janvorli]

I've pushed a fix. The problem was that the VM_HEADERS_WKS_ARCH_ASM that contained the asmconstants.h was being added to VM_SOURCES_WKS_ARCH_ASM, which is a set of files that are to be compiled with assembler. It needed to be added to VM_SOURCES_WKS instead (which is done just to let the header appear in the visual studio solution explorer, cmake is clever enough to not to pass .h files to the C++ compiler).

[jkoritzinsky]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

Of course. I have tested on RHEL 8 using this PR (it works!). I am currently testing on RHEL 8 end-to-end now (using source-build Preview 4 + a manual backport of this patch). If/when that works, RHEL 7 is next on my list.

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

A ./build.sh clr works with commit 265f684da4d370909c70399fd9be4bd089c607b2 after this trivial change:

diff --git a/src/installer/corehost/CMakeLists.txt b/src/installer/corehost/CMakeLists.txt
index 178d8ab..46d1c5e 100644
--- a/src/installer/corehost/CMakeLists.txt+++ b/src/installer/corehost/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
project(corehost)
diff --git a/src/libraries/Native/Unix/CMakeLists.txt b/src/libraries/Native/Unix/CMakeLists.txt
index dee9e51..3168c7e 100644
--- a/src/libraries/Native/Unix/CMakeLists.txt+++ b/src/libraries/Native/Unix/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
if(CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS) # CMake 3.14.5 contains bug fixes for iOS cmake_minimum_required(VERSION 3.14.5) diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index c75e5db..77fcc16 100644
--- a/src/tests/CMakeLists.txt+++ b/src/tests/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
cmake_policy(SET CMP0042 NEW)
project(Tests)

Edit: I am still working on backporting this to preview 4 so I can test end-to-end with source-build (on RHEL 7 and RHEL 8).

[jkoritzinsky]

I've applied your patch. Marking this PR as ready for review/non-work in progress

[akoeplinger]

The non-coreclr specific changes look good to me (can't vouch for the coreclr changes).

[janvorli]

An idea for a future cleanup: This add_library / target_sources pair pattern is used at 24 places. It may be nice to clean this up in a follow up change by creating a cmake function for this pattern. Or even encapsulate the add_library_clr in that function, getting something along these lines:

add_intermediate_library_clr(bcltype${BCLTYPE_SOURCES})
add_intermediate_library_dependencies(bcltypeeventing_headers)

[jkoritzinsky]

Yes, we should clean this up in the future by making some additional functions.

[janvorli]

I wonder why was this change needed. Linking to the static libraries should work fine. The only case when we need to use object libraries is when a static library is built as a combination of other libraries, but it is not the case here.

[jkoritzinsky]

The libhostfxr_static and libhostpolicy_static targets are object libraries. The corehost CMake infra could really use some updates and cleanup to be more straightforward. I'd like to do that in a future PR.

[janvorli]

Hmm, interesting. I can see that they were changed to object ones few months ago and I am not sure why.

I agree that the corehost cmakefiles are very difficult to mentally parse. They looks as if msbuild style of build programming was used here. Instead of using functions for doing common stuff, ambient cmake variables are being set and then common helper cmake files included. I'd love to see it transformed to a natural cmake way at some point.

[jeffschwMSFT]

cc @mmitche

[jkoritzinsky]

@janvorli any more comments?

[janvorli]

LGTM, thank you!

[janvorli]

@jkoritzinsky no, I have thought I've already approved it, but I can see I haven't. So I've just done that.

[jashook]

Thank you @jkoritzinsky for driving this effort!

[jashook]

@omajid which version of clang are we using on redhat 7 for source build? We noticed that by default centos 7 installs 3.4 which we do not support building with.

/cc @janvorli@jkoritzinsky

[omajid]

which version of clang are we using on redhat 7 for source build?

We have generally used llvm-toolset-7.0-cmake (CentOS version here), which is 3.6.2.

This is how we are building 3.1 with llvm-toolset-7.0: https://git.centos.org/rpms/rh-dotnet31-dotnet/blob/c7-dotnet/f/SPECS/dotnet.spec#_314. I don't have a 5.0 version yet, because I haven't been able to build source-build there.

[jashook]

Clean builds using the following:

Os	Cmake	Clang/llvm
Centos 7	3.6.2	7
Centos 8	3.11.4	8

[mmitche]

@jeffschwMSFT Was this supposed to be ported to p8?

[jeffschwMSFT]

@mmitche yes, @jashook is working on the port.

[omajid]

I did a port to preview 4, so I could build against older cmake versions using source-build. Source-build is currently at 5.0 Preview 4. Port is available here: https://github.com/omajid/runtime/tree/5.0-preview4-cmake-backport

[jkoritzinsky]

Downgrade the minimum version of CMake to 3.6.2 for our Linux builds and change our CMake scripts appropriately:

Currently completed steps:

• Provide our own implementation of add_compile_definitions since it is easily polyfillable
• Move away from add_link_options since it is not easy to create our own implementation of that functions the same. Move back to setting linker options via the flag properties.
• Manually enable PIE/PIC on Linux/Mac (this support was added in CMake 3.9)
• Manually check for IPO support on Linux/Mac (this support was added in CMake 3.13)
• Revert to the old CMake command line (this support was added in CMake 3.10)

So far I've only undone the changes that I made in dotnet/coreclr#26980 that I know are required. @janvorli can you help out with some of the other issues that we'll encounter when lowering the CMake version? I don't know all of the corner case behaviors that we've started to depend on in the last 10ish months.

Validation that we actually build on CMake 3.6.2 will come when we get a new Docker image has CMake 3.6.2 (and no newer) installed (@jashook is working on this).

Contributes to #38755

Depends on dotnet/arcade#5770

cc: @dleeapho@janvorli@jashook@omajid@jkotas@tmds@wfurt@RheaAyase

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[omajid]

Thanks for this PR!

I tried building ad16a9797a2e899caec8a610f667789e0bec6524 using ./build.sh on RHEL 8. It doesn't seem to work. This is cmake version 3.11.4

 Detected Linux x86_64 -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG - Success -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/clang CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/static/CMakeLists.txt:41 (include) -- Performing Test HAVE_DIRENT_D_TYPE -- Performing Test HAVE_DIRENT_D_TYPE - Success Looking for coreclr_static lib at location: '/home/dotnet/runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib'. CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/standalone/CMakeLists.txt:39 (include) CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/dotnet/CMakeLists.txt:16 (include) CMake Error at cli/fxr/standalone/CMakeLists.txt:51 (target_link_libraries): Target "libhostfxr_static" of type OBJECT_LIBRARY may not be linked into another target. One may link only to INTERFACE, STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. CMake Error at cli/test/mockhostfxr/CMakeLists.txt:4 (cmake_minimum_required): CMake 3.14.5 or higher is required. You are running version 3.11.4 -- Configuring incomplete, errors occurred!

Please let me know if there's anything I can do to help.

[jkoritzinsky]

I've fixed the issues that I've found relatively simple (removing the unknown policy and removing the extra cmake_minimum_required), but I'm not sure how to fix the libhostfxr_static linking issue. If you know how to downgrade that, I'd appreciate the help.

[omajid]

If you know how to downgrade that, I'd appreciate the help.

Not off the top of my head. I will dig around.

[janvorli]

but I'm not sure how to fix the libhostfxr_static linking issue

The object libraries cannot be used as regular libraries to link to prior to cmake 3.14. All places need to be changed so that the objects from the object libraries are added to the respective targets like source files. E.g.:

add_library(... $<TARGET_OBJECTS:objlib> ...)

[jashook]

I am having trouble building with 3.6.2. Seems that https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/eventing/CMakeLists.txt#L11 requires cmake 3.8+.

How did you get around this @jkoritzinsky

[jkoritzinsky]

I forgot about that. I need to roll that back to use the old find python module.

[jkoritzinsky]

@safern can you take a look at the libraries build failures on OSX?

[janvorli]

I've pushed a fix. The problem was that the VM_HEADERS_WKS_ARCH_ASM that contained the asmconstants.h was being added to VM_SOURCES_WKS_ARCH_ASM, which is a set of files that are to be compiled with assembler. It needed to be added to VM_SOURCES_WKS instead (which is done just to let the header appear in the visual studio solution explorer, cmake is clever enough to not to pass .h files to the C++ compiler).

[jkoritzinsky]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

Of course. I have tested on RHEL 8 using this PR (it works!). I am currently testing on RHEL 8 end-to-end now (using source-build Preview 4 + a manual backport of this patch). If/when that works, RHEL 7 is next on my list.

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

A ./build.sh clr works with commit 265f684da4d370909c70399fd9be4bd089c607b2 after this trivial change:

diff --git a/src/installer/corehost/CMakeLists.txt b/src/installer/corehost/CMakeLists.txt
index 178d8ab..46d1c5e 100644
--- a/src/installer/corehost/CMakeLists.txt+++ b/src/installer/corehost/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
project(corehost)
diff --git a/src/libraries/Native/Unix/CMakeLists.txt b/src/libraries/Native/Unix/CMakeLists.txt
index dee9e51..3168c7e 100644
--- a/src/libraries/Native/Unix/CMakeLists.txt+++ b/src/libraries/Native/Unix/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
if(CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS) # CMake 3.14.5 contains bug fixes for iOS cmake_minimum_required(VERSION 3.14.5) diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index c75e5db..77fcc16 100644
--- a/src/tests/CMakeLists.txt+++ b/src/tests/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
cmake_policy(SET CMP0042 NEW)
project(Tests)

Edit: I am still working on backporting this to preview 4 so I can test end-to-end with source-build (on RHEL 7 and RHEL 8).

[jkoritzinsky]

I've applied your patch. Marking this PR as ready for review/non-work in progress

[akoeplinger]

The non-coreclr specific changes look good to me (can't vouch for the coreclr changes).

[janvorli]

An idea for a future cleanup: This add_library / target_sources pair pattern is used at 24 places. It may be nice to clean this up in a follow up change by creating a cmake function for this pattern. Or even encapsulate the add_library_clr in that function, getting something along these lines:

add_intermediate_library_clr(bcltype${BCLTYPE_SOURCES})
add_intermediate_library_dependencies(bcltypeeventing_headers)

[jkoritzinsky]

Yes, we should clean this up in the future by making some additional functions.

[janvorli]

I wonder why was this change needed. Linking to the static libraries should work fine. The only case when we need to use object libraries is when a static library is built as a combination of other libraries, but it is not the case here.

[jkoritzinsky]

The libhostfxr_static and libhostpolicy_static targets are object libraries. The corehost CMake infra could really use some updates and cleanup to be more straightforward. I'd like to do that in a future PR.

[janvorli]

Hmm, interesting. I can see that they were changed to object ones few months ago and I am not sure why.

I agree that the corehost cmakefiles are very difficult to mentally parse. They looks as if msbuild style of build programming was used here. Instead of using functions for doing common stuff, ambient cmake variables are being set and then common helper cmake files included. I'd love to see it transformed to a natural cmake way at some point.

[jeffschwMSFT]

cc @mmitche

[jkoritzinsky]

@janvorli any more comments?

[janvorli]

LGTM, thank you!

[janvorli]

@jkoritzinsky no, I have thought I've already approved it, but I can see I haven't. So I've just done that.

[jashook]

Thank you @jkoritzinsky for driving this effort!

[jashook]

@omajid which version of clang are we using on redhat 7 for source build? We noticed that by default centos 7 installs 3.4 which we do not support building with.

/cc @janvorli@jkoritzinsky

[omajid]

which version of clang are we using on redhat 7 for source build?

We have generally used llvm-toolset-7.0-cmake (CentOS version here), which is 3.6.2.

This is how we are building 3.1 with llvm-toolset-7.0: https://git.centos.org/rpms/rh-dotnet31-dotnet/blob/c7-dotnet/f/SPECS/dotnet.spec#_314. I don't have a 5.0 version yet, because I haven't been able to build source-build there.

[jashook]

Clean builds using the following:

Os	Cmake	Clang/llvm
Centos 7	3.6.2	7
Centos 8	3.11.4	8

[mmitche]

@jeffschwMSFT Was this supposed to be ported to p8?

[jeffschwMSFT]

@mmitche yes, @jashook is working on the port.

[omajid]

I did a port to preview 4, so I could build against older cmake versions using source-build. Source-build is currently at 5.0 Preview 4. Port is available here: https://github.com/omajid/runtime/tree/5.0-preview4-cmake-backport

[jkoritzinsky]

Downgrade the minimum version of CMake to 3.6.2 for our Linux builds and change our CMake scripts appropriately:

Currently completed steps:

• Provide our own implementation of add_compile_definitions since it is easily polyfillable
• Move away from add_link_options since it is not easy to create our own implementation of that functions the same. Move back to setting linker options via the flag properties.
• Manually enable PIE/PIC on Linux/Mac (this support was added in CMake 3.9)
• Manually check for IPO support on Linux/Mac (this support was added in CMake 3.13)
• Revert to the old CMake command line (this support was added in CMake 3.10)

So far I've only undone the changes that I made in dotnet/coreclr#26980 that I know are required. @janvorli can you help out with some of the other issues that we'll encounter when lowering the CMake version? I don't know all of the corner case behaviors that we've started to depend on in the last 10ish months.

Validation that we actually build on CMake 3.6.2 will come when we get a new Docker image has CMake 3.6.2 (and no newer) installed (@jashook is working on this).

Contributes to #38755

Depends on dotnet/arcade#5770

cc: @dleeapho@janvorli@jashook@omajid@jkotas@tmds@wfurt@RheaAyase

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[omajid]

Thanks for this PR!

I tried building ad16a9797a2e899caec8a610f667789e0bec6524 using ./build.sh on RHEL 8. It doesn't seem to work. This is cmake version 3.11.4

 Detected Linux x86_64 -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG - Success -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/clang CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/static/CMakeLists.txt:41 (include) -- Performing Test HAVE_DIRENT_D_TYPE -- Performing Test HAVE_DIRENT_D_TYPE - Success Looking for coreclr_static lib at location: '/home/dotnet/runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib'. CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/standalone/CMakeLists.txt:39 (include) CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/dotnet/CMakeLists.txt:16 (include) CMake Error at cli/fxr/standalone/CMakeLists.txt:51 (target_link_libraries): Target "libhostfxr_static" of type OBJECT_LIBRARY may not be linked into another target. One may link only to INTERFACE, STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. CMake Error at cli/test/mockhostfxr/CMakeLists.txt:4 (cmake_minimum_required): CMake 3.14.5 or higher is required. You are running version 3.11.4 -- Configuring incomplete, errors occurred!

Please let me know if there's anything I can do to help.

[jkoritzinsky]

I've fixed the issues that I've found relatively simple (removing the unknown policy and removing the extra cmake_minimum_required), but I'm not sure how to fix the libhostfxr_static linking issue. If you know how to downgrade that, I'd appreciate the help.

[omajid]

If you know how to downgrade that, I'd appreciate the help.

Not off the top of my head. I will dig around.

[janvorli]

but I'm not sure how to fix the libhostfxr_static linking issue

The object libraries cannot be used as regular libraries to link to prior to cmake 3.14. All places need to be changed so that the objects from the object libraries are added to the respective targets like source files. E.g.:

add_library(... $<TARGET_OBJECTS:objlib> ...)

[jashook]

I am having trouble building with 3.6.2. Seems that https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/eventing/CMakeLists.txt#L11 requires cmake 3.8+.

How did you get around this @jkoritzinsky

[jkoritzinsky]

I forgot about that. I need to roll that back to use the old find python module.

[jkoritzinsky]

@safern can you take a look at the libraries build failures on OSX?

[janvorli]

I've pushed a fix. The problem was that the VM_HEADERS_WKS_ARCH_ASM that contained the asmconstants.h was being added to VM_SOURCES_WKS_ARCH_ASM, which is a set of files that are to be compiled with assembler. It needed to be added to VM_SOURCES_WKS instead (which is done just to let the header appear in the visual studio solution explorer, cmake is clever enough to not to pass .h files to the C++ compiler).

[jkoritzinsky]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

Of course. I have tested on RHEL 8 using this PR (it works!). I am currently testing on RHEL 8 end-to-end now (using source-build Preview 4 + a manual backport of this patch). If/when that works, RHEL 7 is next on my list.

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

A ./build.sh clr works with commit 265f684da4d370909c70399fd9be4bd089c607b2 after this trivial change:

diff --git a/src/installer/corehost/CMakeLists.txt b/src/installer/corehost/CMakeLists.txt
index 178d8ab..46d1c5e 100644
--- a/src/installer/corehost/CMakeLists.txt+++ b/src/installer/corehost/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
project(corehost)
diff --git a/src/libraries/Native/Unix/CMakeLists.txt b/src/libraries/Native/Unix/CMakeLists.txt
index dee9e51..3168c7e 100644
--- a/src/libraries/Native/Unix/CMakeLists.txt+++ b/src/libraries/Native/Unix/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
if(CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS) # CMake 3.14.5 contains bug fixes for iOS cmake_minimum_required(VERSION 3.14.5) diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index c75e5db..77fcc16 100644
--- a/src/tests/CMakeLists.txt+++ b/src/tests/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
cmake_policy(SET CMP0042 NEW)
project(Tests)

Edit: I am still working on backporting this to preview 4 so I can test end-to-end with source-build (on RHEL 7 and RHEL 8).

[jkoritzinsky]

I've applied your patch. Marking this PR as ready for review/non-work in progress

[akoeplinger]

The non-coreclr specific changes look good to me (can't vouch for the coreclr changes).

[janvorli]

An idea for a future cleanup: This add_library / target_sources pair pattern is used at 24 places. It may be nice to clean this up in a follow up change by creating a cmake function for this pattern. Or even encapsulate the add_library_clr in that function, getting something along these lines:

add_intermediate_library_clr(bcltype${BCLTYPE_SOURCES})
add_intermediate_library_dependencies(bcltypeeventing_headers)

[jkoritzinsky]

Yes, we should clean this up in the future by making some additional functions.

[janvorli]

I wonder why was this change needed. Linking to the static libraries should work fine. The only case when we need to use object libraries is when a static library is built as a combination of other libraries, but it is not the case here.

[jkoritzinsky]

The libhostfxr_static and libhostpolicy_static targets are object libraries. The corehost CMake infra could really use some updates and cleanup to be more straightforward. I'd like to do that in a future PR.

[janvorli]

Hmm, interesting. I can see that they were changed to object ones few months ago and I am not sure why.

I agree that the corehost cmakefiles are very difficult to mentally parse. They looks as if msbuild style of build programming was used here. Instead of using functions for doing common stuff, ambient cmake variables are being set and then common helper cmake files included. I'd love to see it transformed to a natural cmake way at some point.

[jeffschwMSFT]

cc @mmitche

[jkoritzinsky]

@janvorli any more comments?

[janvorli]

LGTM, thank you!

[janvorli]

@jkoritzinsky no, I have thought I've already approved it, but I can see I haven't. So I've just done that.

[jashook]

Thank you @jkoritzinsky for driving this effort!

[jashook]

@omajid which version of clang are we using on redhat 7 for source build? We noticed that by default centos 7 installs 3.4 which we do not support building with.

/cc @janvorli@jkoritzinsky

[omajid]

which version of clang are we using on redhat 7 for source build?

We have generally used llvm-toolset-7.0-cmake (CentOS version here), which is 3.6.2.

This is how we are building 3.1 with llvm-toolset-7.0: https://git.centos.org/rpms/rh-dotnet31-dotnet/blob/c7-dotnet/f/SPECS/dotnet.spec#_314. I don't have a 5.0 version yet, because I haven't been able to build source-build there.

[jashook]

Clean builds using the following:

Os	Cmake	Clang/llvm
Centos 7	3.6.2	7
Centos 8	3.11.4	8

[mmitche]

@jeffschwMSFT Was this supposed to be ported to p8?

[jeffschwMSFT]

@mmitche yes, @jashook is working on the port.

[omajid]

I did a port to preview 4, so I could build against older cmake versions using source-build. Source-build is currently at 5.0 Preview 4. Port is available here: https://github.com/omajid/runtime/tree/5.0-preview4-cmake-backport

[jkoritzinsky]

Downgrade the minimum version of CMake to 3.6.2 for our Linux builds and change our CMake scripts appropriately:

Currently completed steps:

• Provide our own implementation of add_compile_definitions since it is easily polyfillable
• Move away from add_link_options since it is not easy to create our own implementation of that functions the same. Move back to setting linker options via the flag properties.
• Manually enable PIE/PIC on Linux/Mac (this support was added in CMake 3.9)
• Manually check for IPO support on Linux/Mac (this support was added in CMake 3.13)
• Revert to the old CMake command line (this support was added in CMake 3.10)

So far I've only undone the changes that I made in dotnet/coreclr#26980 that I know are required. @janvorli can you help out with some of the other issues that we'll encounter when lowering the CMake version? I don't know all of the corner case behaviors that we've started to depend on in the last 10ish months.

Validation that we actually build on CMake 3.6.2 will come when we get a new Docker image has CMake 3.6.2 (and no newer) installed (@jashook is working on this).

Contributes to #38755

Depends on dotnet/arcade#5770

cc: @dleeapho@janvorli@jashook@omajid@jkotas@tmds@wfurt@RheaAyase

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[omajid]

Thanks for this PR!

I tried building ad16a9797a2e899caec8a610f667789e0bec6524 using ./build.sh on RHEL 8. It doesn't seem to work. This is cmake version 3.11.4

 Detected Linux x86_64 -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG - Success -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/clang CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/static/CMakeLists.txt:41 (include) -- Performing Test HAVE_DIRENT_D_TYPE -- Performing Test HAVE_DIRENT_D_TYPE - Success Looking for coreclr_static lib at location: '/home/dotnet/runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib'. CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/standalone/CMakeLists.txt:39 (include) CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/dotnet/CMakeLists.txt:16 (include) CMake Error at cli/fxr/standalone/CMakeLists.txt:51 (target_link_libraries): Target "libhostfxr_static" of type OBJECT_LIBRARY may not be linked into another target. One may link only to INTERFACE, STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. CMake Error at cli/test/mockhostfxr/CMakeLists.txt:4 (cmake_minimum_required): CMake 3.14.5 or higher is required. You are running version 3.11.4 -- Configuring incomplete, errors occurred!

Please let me know if there's anything I can do to help.

[jkoritzinsky]

I've fixed the issues that I've found relatively simple (removing the unknown policy and removing the extra cmake_minimum_required), but I'm not sure how to fix the libhostfxr_static linking issue. If you know how to downgrade that, I'd appreciate the help.

[omajid]

If you know how to downgrade that, I'd appreciate the help.

Not off the top of my head. I will dig around.

[janvorli]

but I'm not sure how to fix the libhostfxr_static linking issue

The object libraries cannot be used as regular libraries to link to prior to cmake 3.14. All places need to be changed so that the objects from the object libraries are added to the respective targets like source files. E.g.:

add_library(... $<TARGET_OBJECTS:objlib> ...)

[jashook]

I am having trouble building with 3.6.2. Seems that https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/eventing/CMakeLists.txt#L11 requires cmake 3.8+.

How did you get around this @jkoritzinsky

[jkoritzinsky]

I forgot about that. I need to roll that back to use the old find python module.

[jkoritzinsky]

@safern can you take a look at the libraries build failures on OSX?

[janvorli]

I've pushed a fix. The problem was that the VM_HEADERS_WKS_ARCH_ASM that contained the asmconstants.h was being added to VM_SOURCES_WKS_ARCH_ASM, which is a set of files that are to be compiled with assembler. It needed to be added to VM_SOURCES_WKS instead (which is done just to let the header appear in the visual studio solution explorer, cmake is clever enough to not to pass .h files to the C++ compiler).

[jkoritzinsky]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

Of course. I have tested on RHEL 8 using this PR (it works!). I am currently testing on RHEL 8 end-to-end now (using source-build Preview 4 + a manual backport of this patch). If/when that works, RHEL 7 is next on my list.

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

A ./build.sh clr works with commit 265f684da4d370909c70399fd9be4bd089c607b2 after this trivial change:

diff --git a/src/installer/corehost/CMakeLists.txt b/src/installer/corehost/CMakeLists.txt
index 178d8ab..46d1c5e 100644
--- a/src/installer/corehost/CMakeLists.txt+++ b/src/installer/corehost/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
project(corehost)
diff --git a/src/libraries/Native/Unix/CMakeLists.txt b/src/libraries/Native/Unix/CMakeLists.txt
index dee9e51..3168c7e 100644
--- a/src/libraries/Native/Unix/CMakeLists.txt+++ b/src/libraries/Native/Unix/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
if(CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS) # CMake 3.14.5 contains bug fixes for iOS cmake_minimum_required(VERSION 3.14.5) diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index c75e5db..77fcc16 100644
--- a/src/tests/CMakeLists.txt+++ b/src/tests/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
cmake_policy(SET CMP0042 NEW)
project(Tests)

Edit: I am still working on backporting this to preview 4 so I can test end-to-end with source-build (on RHEL 7 and RHEL 8).

[jkoritzinsky]

I've applied your patch. Marking this PR as ready for review/non-work in progress

[akoeplinger]

The non-coreclr specific changes look good to me (can't vouch for the coreclr changes).

[janvorli]

An idea for a future cleanup: This add_library / target_sources pair pattern is used at 24 places. It may be nice to clean this up in a follow up change by creating a cmake function for this pattern. Or even encapsulate the add_library_clr in that function, getting something along these lines:

add_intermediate_library_clr(bcltype${BCLTYPE_SOURCES})
add_intermediate_library_dependencies(bcltypeeventing_headers)

[jkoritzinsky]

Yes, we should clean this up in the future by making some additional functions.

[janvorli]

I wonder why was this change needed. Linking to the static libraries should work fine. The only case when we need to use object libraries is when a static library is built as a combination of other libraries, but it is not the case here.

[jkoritzinsky]

The libhostfxr_static and libhostpolicy_static targets are object libraries. The corehost CMake infra could really use some updates and cleanup to be more straightforward. I'd like to do that in a future PR.

[janvorli]

Hmm, interesting. I can see that they were changed to object ones few months ago and I am not sure why.

I agree that the corehost cmakefiles are very difficult to mentally parse. They looks as if msbuild style of build programming was used here. Instead of using functions for doing common stuff, ambient cmake variables are being set and then common helper cmake files included. I'd love to see it transformed to a natural cmake way at some point.

[jeffschwMSFT]

cc @mmitche

[jkoritzinsky]

@janvorli any more comments?

[janvorli]

LGTM, thank you!

[janvorli]

@jkoritzinsky no, I have thought I've already approved it, but I can see I haven't. So I've just done that.

[jashook]

Thank you @jkoritzinsky for driving this effort!

[jashook]

@omajid which version of clang are we using on redhat 7 for source build? We noticed that by default centos 7 installs 3.4 which we do not support building with.

/cc @janvorli@jkoritzinsky

[omajid]

which version of clang are we using on redhat 7 for source build?

We have generally used llvm-toolset-7.0-cmake (CentOS version here), which is 3.6.2.

This is how we are building 3.1 with llvm-toolset-7.0: https://git.centos.org/rpms/rh-dotnet31-dotnet/blob/c7-dotnet/f/SPECS/dotnet.spec#_314. I don't have a 5.0 version yet, because I haven't been able to build source-build there.

[jashook]

Clean builds using the following:

Os	Cmake	Clang/llvm
Centos 7	3.6.2	7
Centos 8	3.11.4	8

[mmitche]

@jeffschwMSFT Was this supposed to be ported to p8?

[jeffschwMSFT]

@mmitche yes, @jashook is working on the port.

[omajid]

I did a port to preview 4, so I could build against older cmake versions using source-build. Source-build is currently at 5.0 Preview 4. Port is available here: https://github.com/omajid/runtime/tree/5.0-preview4-cmake-backport

[jkoritzinsky]

Downgrade the minimum version of CMake to 3.6.2 for our Linux builds and change our CMake scripts appropriately:

Currently completed steps:

• Provide our own implementation of add_compile_definitions since it is easily polyfillable
• Move away from add_link_options since it is not easy to create our own implementation of that functions the same. Move back to setting linker options via the flag properties.
• Manually enable PIE/PIC on Linux/Mac (this support was added in CMake 3.9)
• Manually check for IPO support on Linux/Mac (this support was added in CMake 3.13)
• Revert to the old CMake command line (this support was added in CMake 3.10)

So far I've only undone the changes that I made in dotnet/coreclr#26980 that I know are required. @janvorli can you help out with some of the other issues that we'll encounter when lowering the CMake version? I don't know all of the corner case behaviors that we've started to depend on in the last 10ish months.

Validation that we actually build on CMake 3.6.2 will come when we get a new Docker image has CMake 3.6.2 (and no newer) installed (@jashook is working on this).

Contributes to #38755

Depends on dotnet/arcade#5770

cc: @dleeapho@janvorli@jashook@omajid@jkotas@tmds@wfurt@RheaAyase

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[omajid]

Thanks for this PR!

I tried building ad16a9797a2e899caec8a610f667789e0bec6524 using ./build.sh on RHEL 8. It doesn't seem to work. This is cmake version 3.11.4

 Detected Linux x86_64 -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG - Success -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/clang CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/static/CMakeLists.txt:41 (include) -- Performing Test HAVE_DIRENT_D_TYPE -- Performing Test HAVE_DIRENT_D_TYPE - Success Looking for coreclr_static lib at location: '/home/dotnet/runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib'. CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/standalone/CMakeLists.txt:39 (include) CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/dotnet/CMakeLists.txt:16 (include) CMake Error at cli/fxr/standalone/CMakeLists.txt:51 (target_link_libraries): Target "libhostfxr_static" of type OBJECT_LIBRARY may not be linked into another target. One may link only to INTERFACE, STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. CMake Error at cli/test/mockhostfxr/CMakeLists.txt:4 (cmake_minimum_required): CMake 3.14.5 or higher is required. You are running version 3.11.4 -- Configuring incomplete, errors occurred!

Please let me know if there's anything I can do to help.

[jkoritzinsky]

I've fixed the issues that I've found relatively simple (removing the unknown policy and removing the extra cmake_minimum_required), but I'm not sure how to fix the libhostfxr_static linking issue. If you know how to downgrade that, I'd appreciate the help.

[omajid]

If you know how to downgrade that, I'd appreciate the help.

Not off the top of my head. I will dig around.

[janvorli]

but I'm not sure how to fix the libhostfxr_static linking issue

The object libraries cannot be used as regular libraries to link to prior to cmake 3.14. All places need to be changed so that the objects from the object libraries are added to the respective targets like source files. E.g.:

add_library(... $<TARGET_OBJECTS:objlib> ...)

[jashook]

I am having trouble building with 3.6.2. Seems that https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/eventing/CMakeLists.txt#L11 requires cmake 3.8+.

How did you get around this @jkoritzinsky

[jkoritzinsky]

I forgot about that. I need to roll that back to use the old find python module.

[jkoritzinsky]

@safern can you take a look at the libraries build failures on OSX?

[janvorli]

I've pushed a fix. The problem was that the VM_HEADERS_WKS_ARCH_ASM that contained the asmconstants.h was being added to VM_SOURCES_WKS_ARCH_ASM, which is a set of files that are to be compiled with assembler. It needed to be added to VM_SOURCES_WKS instead (which is done just to let the header appear in the visual studio solution explorer, cmake is clever enough to not to pass .h files to the C++ compiler).

[jkoritzinsky]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

Of course. I have tested on RHEL 8 using this PR (it works!). I am currently testing on RHEL 8 end-to-end now (using source-build Preview 4 + a manual backport of this patch). If/when that works, RHEL 7 is next on my list.

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

A ./build.sh clr works with commit 265f684da4d370909c70399fd9be4bd089c607b2 after this trivial change:

diff --git a/src/installer/corehost/CMakeLists.txt b/src/installer/corehost/CMakeLists.txt
index 178d8ab..46d1c5e 100644
--- a/src/installer/corehost/CMakeLists.txt+++ b/src/installer/corehost/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
project(corehost)
diff --git a/src/libraries/Native/Unix/CMakeLists.txt b/src/libraries/Native/Unix/CMakeLists.txt
index dee9e51..3168c7e 100644
--- a/src/libraries/Native/Unix/CMakeLists.txt+++ b/src/libraries/Native/Unix/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
if(CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS) # CMake 3.14.5 contains bug fixes for iOS cmake_minimum_required(VERSION 3.14.5) diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index c75e5db..77fcc16 100644
--- a/src/tests/CMakeLists.txt+++ b/src/tests/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
cmake_policy(SET CMP0042 NEW)
project(Tests)

Edit: I am still working on backporting this to preview 4 so I can test end-to-end with source-build (on RHEL 7 and RHEL 8).

[jkoritzinsky]

I've applied your patch. Marking this PR as ready for review/non-work in progress

[akoeplinger]

The non-coreclr specific changes look good to me (can't vouch for the coreclr changes).

[janvorli]

An idea for a future cleanup: This add_library / target_sources pair pattern is used at 24 places. It may be nice to clean this up in a follow up change by creating a cmake function for this pattern. Or even encapsulate the add_library_clr in that function, getting something along these lines:

add_intermediate_library_clr(bcltype${BCLTYPE_SOURCES})
add_intermediate_library_dependencies(bcltypeeventing_headers)

[jkoritzinsky]

Yes, we should clean this up in the future by making some additional functions.

[janvorli]

I wonder why was this change needed. Linking to the static libraries should work fine. The only case when we need to use object libraries is when a static library is built as a combination of other libraries, but it is not the case here.

[jkoritzinsky]

The libhostfxr_static and libhostpolicy_static targets are object libraries. The corehost CMake infra could really use some updates and cleanup to be more straightforward. I'd like to do that in a future PR.

[janvorli]

Hmm, interesting. I can see that they were changed to object ones few months ago and I am not sure why.

I agree that the corehost cmakefiles are very difficult to mentally parse. They looks as if msbuild style of build programming was used here. Instead of using functions for doing common stuff, ambient cmake variables are being set and then common helper cmake files included. I'd love to see it transformed to a natural cmake way at some point.

[jeffschwMSFT]

cc @mmitche

[jkoritzinsky]

@janvorli any more comments?

[janvorli]

LGTM, thank you!

[janvorli]

@jkoritzinsky no, I have thought I've already approved it, but I can see I haven't. So I've just done that.

[jashook]

Thank you @jkoritzinsky for driving this effort!

[jashook]

@omajid which version of clang are we using on redhat 7 for source build? We noticed that by default centos 7 installs 3.4 which we do not support building with.

/cc @janvorli@jkoritzinsky

[omajid]

which version of clang are we using on redhat 7 for source build?

We have generally used llvm-toolset-7.0-cmake (CentOS version here), which is 3.6.2.

This is how we are building 3.1 with llvm-toolset-7.0: https://git.centos.org/rpms/rh-dotnet31-dotnet/blob/c7-dotnet/f/SPECS/dotnet.spec#_314. I don't have a 5.0 version yet, because I haven't been able to build source-build there.

[jashook]

Clean builds using the following:

Os	Cmake	Clang/llvm
Centos 7	3.6.2	7
Centos 8	3.11.4	8

[mmitche]

@jeffschwMSFT Was this supposed to be ported to p8?

[jeffschwMSFT]

@mmitche yes, @jashook is working on the port.

[omajid]

I did a port to preview 4, so I could build against older cmake versions using source-build. Source-build is currently at 5.0 Preview 4. Port is available here: https://github.com/omajid/runtime/tree/5.0-preview4-cmake-backport

[jkoritzinsky]

Downgrade the minimum version of CMake to 3.6.2 for our Linux builds and change our CMake scripts appropriately:

Currently completed steps:

• Provide our own implementation of add_compile_definitions since it is easily polyfillable
• Move away from add_link_options since it is not easy to create our own implementation of that functions the same. Move back to setting linker options via the flag properties.
• Manually enable PIE/PIC on Linux/Mac (this support was added in CMake 3.9)
• Manually check for IPO support on Linux/Mac (this support was added in CMake 3.13)
• Revert to the old CMake command line (this support was added in CMake 3.10)

So far I've only undone the changes that I made in dotnet/coreclr#26980 that I know are required. @janvorli can you help out with some of the other issues that we'll encounter when lowering the CMake version? I don't know all of the corner case behaviors that we've started to depend on in the last 10ish months.

Validation that we actually build on CMake 3.6.2 will come when we get a new Docker image has CMake 3.6.2 (and no newer) installed (@jashook is working on this).

Contributes to #38755

Depends on dotnet/arcade#5770

cc: @dleeapho@janvorli@jashook@omajid@jkotas@tmds@wfurt@RheaAyase

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[omajid]

Thanks for this PR!

I tried building ad16a9797a2e899caec8a610f667789e0bec6524 using ./build.sh on RHEL 8. It doesn't seem to work. This is cmake version 3.11.4

 Detected Linux x86_64 -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG - Success -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/clang CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/static/CMakeLists.txt:41 (include) -- Performing Test HAVE_DIRENT_D_TYPE -- Performing Test HAVE_DIRENT_D_TYPE - Success Looking for coreclr_static lib at location: '/home/dotnet/runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib'. CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/standalone/CMakeLists.txt:39 (include) CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/dotnet/CMakeLists.txt:16 (include) CMake Error at cli/fxr/standalone/CMakeLists.txt:51 (target_link_libraries): Target "libhostfxr_static" of type OBJECT_LIBRARY may not be linked into another target. One may link only to INTERFACE, STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. CMake Error at cli/test/mockhostfxr/CMakeLists.txt:4 (cmake_minimum_required): CMake 3.14.5 or higher is required. You are running version 3.11.4 -- Configuring incomplete, errors occurred!

Please let me know if there's anything I can do to help.

[jkoritzinsky]

I've fixed the issues that I've found relatively simple (removing the unknown policy and removing the extra cmake_minimum_required), but I'm not sure how to fix the libhostfxr_static linking issue. If you know how to downgrade that, I'd appreciate the help.

[omajid]

If you know how to downgrade that, I'd appreciate the help.

Not off the top of my head. I will dig around.

[janvorli]

but I'm not sure how to fix the libhostfxr_static linking issue

The object libraries cannot be used as regular libraries to link to prior to cmake 3.14. All places need to be changed so that the objects from the object libraries are added to the respective targets like source files. E.g.:

add_library(... $<TARGET_OBJECTS:objlib> ...)

[jashook]

I am having trouble building with 3.6.2. Seems that https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/eventing/CMakeLists.txt#L11 requires cmake 3.8+.

How did you get around this @jkoritzinsky

[jkoritzinsky]

I forgot about that. I need to roll that back to use the old find python module.

[jkoritzinsky]

@safern can you take a look at the libraries build failures on OSX?

[janvorli]

I've pushed a fix. The problem was that the VM_HEADERS_WKS_ARCH_ASM that contained the asmconstants.h was being added to VM_SOURCES_WKS_ARCH_ASM, which is a set of files that are to be compiled with assembler. It needed to be added to VM_SOURCES_WKS instead (which is done just to let the header appear in the visual studio solution explorer, cmake is clever enough to not to pass .h files to the C++ compiler).

[jkoritzinsky]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

Of course. I have tested on RHEL 8 using this PR (it works!). I am currently testing on RHEL 8 end-to-end now (using source-build Preview 4 + a manual backport of this patch). If/when that works, RHEL 7 is next on my list.

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

A ./build.sh clr works with commit 265f684da4d370909c70399fd9be4bd089c607b2 after this trivial change:

diff --git a/src/installer/corehost/CMakeLists.txt b/src/installer/corehost/CMakeLists.txt
index 178d8ab..46d1c5e 100644
--- a/src/installer/corehost/CMakeLists.txt+++ b/src/installer/corehost/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
project(corehost)
diff --git a/src/libraries/Native/Unix/CMakeLists.txt b/src/libraries/Native/Unix/CMakeLists.txt
index dee9e51..3168c7e 100644
--- a/src/libraries/Native/Unix/CMakeLists.txt+++ b/src/libraries/Native/Unix/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
if(CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS) # CMake 3.14.5 contains bug fixes for iOS cmake_minimum_required(VERSION 3.14.5) diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index c75e5db..77fcc16 100644
--- a/src/tests/CMakeLists.txt+++ b/src/tests/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
cmake_policy(SET CMP0042 NEW)
project(Tests)

Edit: I am still working on backporting this to preview 4 so I can test end-to-end with source-build (on RHEL 7 and RHEL 8).

[jkoritzinsky]

I've applied your patch. Marking this PR as ready for review/non-work in progress

[akoeplinger]

The non-coreclr specific changes look good to me (can't vouch for the coreclr changes).

[janvorli]

An idea for a future cleanup: This add_library / target_sources pair pattern is used at 24 places. It may be nice to clean this up in a follow up change by creating a cmake function for this pattern. Or even encapsulate the add_library_clr in that function, getting something along these lines:

add_intermediate_library_clr(bcltype${BCLTYPE_SOURCES})
add_intermediate_library_dependencies(bcltypeeventing_headers)

[jkoritzinsky]

Yes, we should clean this up in the future by making some additional functions.

[janvorli]

I wonder why was this change needed. Linking to the static libraries should work fine. The only case when we need to use object libraries is when a static library is built as a combination of other libraries, but it is not the case here.

[jkoritzinsky]

The libhostfxr_static and libhostpolicy_static targets are object libraries. The corehost CMake infra could really use some updates and cleanup to be more straightforward. I'd like to do that in a future PR.

[janvorli]

Hmm, interesting. I can see that they were changed to object ones few months ago and I am not sure why.

I agree that the corehost cmakefiles are very difficult to mentally parse. They looks as if msbuild style of build programming was used here. Instead of using functions for doing common stuff, ambient cmake variables are being set and then common helper cmake files included. I'd love to see it transformed to a natural cmake way at some point.

[jeffschwMSFT]

cc @mmitche

[jkoritzinsky]

@janvorli any more comments?

[janvorli]

LGTM, thank you!

[janvorli]

@jkoritzinsky no, I have thought I've already approved it, but I can see I haven't. So I've just done that.

[jashook]

Thank you @jkoritzinsky for driving this effort!

[jashook]

@omajid which version of clang are we using on redhat 7 for source build? We noticed that by default centos 7 installs 3.4 which we do not support building with.

/cc @janvorli@jkoritzinsky

[omajid]

which version of clang are we using on redhat 7 for source build?

We have generally used llvm-toolset-7.0-cmake (CentOS version here), which is 3.6.2.

This is how we are building 3.1 with llvm-toolset-7.0: https://git.centos.org/rpms/rh-dotnet31-dotnet/blob/c7-dotnet/f/SPECS/dotnet.spec#_314. I don't have a 5.0 version yet, because I haven't been able to build source-build there.

[jashook]

Clean builds using the following:

Os	Cmake	Clang/llvm
Centos 7	3.6.2	7
Centos 8	3.11.4	8

[mmitche]

@jeffschwMSFT Was this supposed to be ported to p8?

[jeffschwMSFT]

@mmitche yes, @jashook is working on the port.

[omajid]

I did a port to preview 4, so I could build against older cmake versions using source-build. Source-build is currently at 5.0 Preview 4. Port is available here: https://github.com/omajid/runtime/tree/5.0-preview4-cmake-backport

[jkoritzinsky]

Downgrade the minimum version of CMake to 3.6.2 for our Linux builds and change our CMake scripts appropriately:

Currently completed steps:

• Provide our own implementation of add_compile_definitions since it is easily polyfillable
• Move away from add_link_options since it is not easy to create our own implementation of that functions the same. Move back to setting linker options via the flag properties.
• Manually enable PIE/PIC on Linux/Mac (this support was added in CMake 3.9)
• Manually check for IPO support on Linux/Mac (this support was added in CMake 3.13)
• Revert to the old CMake command line (this support was added in CMake 3.10)

So far I've only undone the changes that I made in dotnet/coreclr#26980 that I know are required. @janvorli can you help out with some of the other issues that we'll encounter when lowering the CMake version? I don't know all of the corner case behaviors that we've started to depend on in the last 10ish months.

Validation that we actually build on CMake 3.6.2 will come when we get a new Docker image has CMake 3.6.2 (and no newer) installed (@jashook is working on this).

Contributes to #38755

Depends on dotnet/arcade#5770

cc: @dleeapho@janvorli@jashook@omajid@jkotas@tmds@wfurt@RheaAyase

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[omajid]

Thanks for this PR!

I tried building ad16a9797a2e899caec8a610f667789e0bec6524 using ./build.sh on RHEL 8. It doesn't seem to work. This is cmake version 3.11.4

 Detected Linux x86_64 -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG - Success -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/clang CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/static/CMakeLists.txt:41 (include) -- Performing Test HAVE_DIRENT_D_TYPE -- Performing Test HAVE_DIRENT_D_TYPE - Success Looking for coreclr_static lib at location: '/home/dotnet/runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib'. CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/standalone/CMakeLists.txt:39 (include) CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/dotnet/CMakeLists.txt:16 (include) CMake Error at cli/fxr/standalone/CMakeLists.txt:51 (target_link_libraries): Target "libhostfxr_static" of type OBJECT_LIBRARY may not be linked into another target. One may link only to INTERFACE, STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. CMake Error at cli/test/mockhostfxr/CMakeLists.txt:4 (cmake_minimum_required): CMake 3.14.5 or higher is required. You are running version 3.11.4 -- Configuring incomplete, errors occurred!

Please let me know if there's anything I can do to help.

[jkoritzinsky]

I've fixed the issues that I've found relatively simple (removing the unknown policy and removing the extra cmake_minimum_required), but I'm not sure how to fix the libhostfxr_static linking issue. If you know how to downgrade that, I'd appreciate the help.

[omajid]

If you know how to downgrade that, I'd appreciate the help.

Not off the top of my head. I will dig around.

[janvorli]

but I'm not sure how to fix the libhostfxr_static linking issue

The object libraries cannot be used as regular libraries to link to prior to cmake 3.14. All places need to be changed so that the objects from the object libraries are added to the respective targets like source files. E.g.:

add_library(... $<TARGET_OBJECTS:objlib> ...)

[jashook]

I am having trouble building with 3.6.2. Seems that https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/eventing/CMakeLists.txt#L11 requires cmake 3.8+.

How did you get around this @jkoritzinsky

[jkoritzinsky]

I forgot about that. I need to roll that back to use the old find python module.

[jkoritzinsky]

@safern can you take a look at the libraries build failures on OSX?

[janvorli]

I've pushed a fix. The problem was that the VM_HEADERS_WKS_ARCH_ASM that contained the asmconstants.h was being added to VM_SOURCES_WKS_ARCH_ASM, which is a set of files that are to be compiled with assembler. It needed to be added to VM_SOURCES_WKS instead (which is done just to let the header appear in the visual studio solution explorer, cmake is clever enough to not to pass .h files to the C++ compiler).

[jkoritzinsky]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

Of course. I have tested on RHEL 8 using this PR (it works!). I am currently testing on RHEL 8 end-to-end now (using source-build Preview 4 + a manual backport of this patch). If/when that works, RHEL 7 is next on my list.

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

A ./build.sh clr works with commit 265f684da4d370909c70399fd9be4bd089c607b2 after this trivial change:

diff --git a/src/installer/corehost/CMakeLists.txt b/src/installer/corehost/CMakeLists.txt
index 178d8ab..46d1c5e 100644
--- a/src/installer/corehost/CMakeLists.txt+++ b/src/installer/corehost/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
project(corehost)
diff --git a/src/libraries/Native/Unix/CMakeLists.txt b/src/libraries/Native/Unix/CMakeLists.txt
index dee9e51..3168c7e 100644
--- a/src/libraries/Native/Unix/CMakeLists.txt+++ b/src/libraries/Native/Unix/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
if(CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS) # CMake 3.14.5 contains bug fixes for iOS cmake_minimum_required(VERSION 3.14.5) diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index c75e5db..77fcc16 100644
--- a/src/tests/CMakeLists.txt+++ b/src/tests/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
cmake_policy(SET CMP0042 NEW)
project(Tests)

Edit: I am still working on backporting this to preview 4 so I can test end-to-end with source-build (on RHEL 7 and RHEL 8).

[jkoritzinsky]

I've applied your patch. Marking this PR as ready for review/non-work in progress

[akoeplinger]

The non-coreclr specific changes look good to me (can't vouch for the coreclr changes).

[janvorli]

An idea for a future cleanup: This add_library / target_sources pair pattern is used at 24 places. It may be nice to clean this up in a follow up change by creating a cmake function for this pattern. Or even encapsulate the add_library_clr in that function, getting something along these lines:

add_intermediate_library_clr(bcltype${BCLTYPE_SOURCES})
add_intermediate_library_dependencies(bcltypeeventing_headers)

[jkoritzinsky]

Yes, we should clean this up in the future by making some additional functions.

[janvorli]

I wonder why was this change needed. Linking to the static libraries should work fine. The only case when we need to use object libraries is when a static library is built as a combination of other libraries, but it is not the case here.

[jkoritzinsky]

The libhostfxr_static and libhostpolicy_static targets are object libraries. The corehost CMake infra could really use some updates and cleanup to be more straightforward. I'd like to do that in a future PR.

[janvorli]

Hmm, interesting. I can see that they were changed to object ones few months ago and I am not sure why.

I agree that the corehost cmakefiles are very difficult to mentally parse. They looks as if msbuild style of build programming was used here. Instead of using functions for doing common stuff, ambient cmake variables are being set and then common helper cmake files included. I'd love to see it transformed to a natural cmake way at some point.

[jeffschwMSFT]

cc @mmitche

[jkoritzinsky]

@janvorli any more comments?

[janvorli]

LGTM, thank you!

[janvorli]

@jkoritzinsky no, I have thought I've already approved it, but I can see I haven't. So I've just done that.

[jashook]

Thank you @jkoritzinsky for driving this effort!

[jashook]

@omajid which version of clang are we using on redhat 7 for source build? We noticed that by default centos 7 installs 3.4 which we do not support building with.

/cc @janvorli@jkoritzinsky

[omajid]

which version of clang are we using on redhat 7 for source build?

We have generally used llvm-toolset-7.0-cmake (CentOS version here), which is 3.6.2.

This is how we are building 3.1 with llvm-toolset-7.0: https://git.centos.org/rpms/rh-dotnet31-dotnet/blob/c7-dotnet/f/SPECS/dotnet.spec#_314. I don't have a 5.0 version yet, because I haven't been able to build source-build there.

[jashook]

Clean builds using the following:

Os	Cmake	Clang/llvm
Centos 7	3.6.2	7
Centos 8	3.11.4	8

[mmitche]

@jeffschwMSFT Was this supposed to be ported to p8?

[jeffschwMSFT]

@mmitche yes, @jashook is working on the port.

[omajid]

I did a port to preview 4, so I could build against older cmake versions using source-build. Source-build is currently at 5.0 Preview 4. Port is available here: https://github.com/omajid/runtime/tree/5.0-preview4-cmake-backport

[jkoritzinsky]

Downgrade the minimum version of CMake to 3.6.2 for our Linux builds and change our CMake scripts appropriately:

Currently completed steps:

• Provide our own implementation of add_compile_definitions since it is easily polyfillable
• Move away from add_link_options since it is not easy to create our own implementation of that functions the same. Move back to setting linker options via the flag properties.
• Manually enable PIE/PIC on Linux/Mac (this support was added in CMake 3.9)
• Manually check for IPO support on Linux/Mac (this support was added in CMake 3.13)
• Revert to the old CMake command line (this support was added in CMake 3.10)

So far I've only undone the changes that I made in dotnet/coreclr#26980 that I know are required. @janvorli can you help out with some of the other issues that we'll encounter when lowering the CMake version? I don't know all of the corner case behaviors that we've started to depend on in the last 10ish months.

Validation that we actually build on CMake 3.6.2 will come when we get a new Docker image has CMake 3.6.2 (and no newer) installed (@jashook is working on this).

Contributes to #38755

Depends on dotnet/arcade#5770

cc: @dleeapho@janvorli@jashook@omajid@jkotas@tmds@wfurt@RheaAyase

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[omajid]

Thanks for this PR!

I tried building ad16a9797a2e899caec8a610f667789e0bec6524 using ./build.sh on RHEL 8. It doesn't seem to work. This is cmake version 3.11.4

 Detected Linux x86_64 -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG -- Performing Test COMPILER_SUPPORTS_F_STACK_PROTECTOR_STRONG - Success -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/clang CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/static/CMakeLists.txt:41 (include) -- Performing Test HAVE_DIRENT_D_TYPE -- Performing Test HAVE_DIRENT_D_TYPE - Success Looking for coreclr_static lib at location: '/home/dotnet/runtime/artifacts/bin/coreclr/Linux.x64.Debug//lib'. CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/apphost/standalone/CMakeLists.txt:39 (include) CMake Error at cli/exe.cmake:7 (cmake_policy): Policy "CMP0083" is not known to this version of CMake. Call Stack (most recent call first): cli/dotnet/CMakeLists.txt:16 (include) CMake Error at cli/fxr/standalone/CMakeLists.txt:51 (target_link_libraries): Target "libhostfxr_static" of type OBJECT_LIBRARY may not be linked into another target. One may link only to INTERFACE, STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. CMake Error at cli/test/mockhostfxr/CMakeLists.txt:4 (cmake_minimum_required): CMake 3.14.5 or higher is required. You are running version 3.11.4 -- Configuring incomplete, errors occurred!

Please let me know if there's anything I can do to help.

[jkoritzinsky]

I've fixed the issues that I've found relatively simple (removing the unknown policy and removing the extra cmake_minimum_required), but I'm not sure how to fix the libhostfxr_static linking issue. If you know how to downgrade that, I'd appreciate the help.

[omajid]

If you know how to downgrade that, I'd appreciate the help.

Not off the top of my head. I will dig around.

[janvorli]

but I'm not sure how to fix the libhostfxr_static linking issue

The object libraries cannot be used as regular libraries to link to prior to cmake 3.14. All places need to be changed so that the objects from the object libraries are added to the respective targets like source files. E.g.:

add_library(... $<TARGET_OBJECTS:objlib> ...)

[jashook]

I am having trouble building with 3.6.2. Seems that https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/eventing/CMakeLists.txt#L11 requires cmake 3.8+.

How did you get around this @jkoritzinsky

[jkoritzinsky]

I forgot about that. I need to roll that back to use the old find python module.

[jkoritzinsky]

@safern can you take a look at the libraries build failures on OSX?

[janvorli]

I've pushed a fix. The problem was that the VM_HEADERS_WKS_ARCH_ASM that contained the asmconstants.h was being added to VM_SOURCES_WKS_ARCH_ASM, which is a set of files that are to be compiled with assembler. It needed to be added to VM_SOURCES_WKS instead (which is done just to let the header appear in the visual studio solution explorer, cmake is clever enough to not to pass .h files to the C++ compiler).

[jkoritzinsky]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

Of course. I have tested on RHEL 8 using this PR (it works!). I am currently testing on RHEL 8 end-to-end now (using source-build Preview 4 + a manual backport of this patch). If/when that works, RHEL 7 is next on my list.

[omajid]

@omajid can you do a test build against the RHEL 7 image you'll be building against for the distro build?

A ./build.sh clr works with commit 265f684da4d370909c70399fd9be4bd089c607b2 after this trivial change:

diff --git a/src/installer/corehost/CMakeLists.txt b/src/installer/corehost/CMakeLists.txt
index 178d8ab..46d1c5e 100644
--- a/src/installer/corehost/CMakeLists.txt+++ b/src/installer/corehost/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
project(corehost)
diff --git a/src/libraries/Native/Unix/CMakeLists.txt b/src/libraries/Native/Unix/CMakeLists.txt
index dee9e51..3168c7e 100644
--- a/src/libraries/Native/Unix/CMakeLists.txt+++ b/src/libraries/Native/Unix/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
if(CLR_CMAKE_TARGET_IOS OR CLR_CMAKE_TARGET_TVOS) # CMake 3.14.5 contains bug fixes for iOS cmake_minimum_required(VERSION 3.14.5) diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index c75e5db..77fcc16 100644
--- a/src/tests/CMakeLists.txt+++ b/src/tests/CMakeLists.txt@@ -1,4 +1,4 @@-cmake_minimum_required(VERSION 3.6.3)+cmake_minimum_required(VERSION 3.6.2)
cmake_policy(SET CMP0042 NEW)
project(Tests)

Edit: I am still working on backporting this to preview 4 so I can test end-to-end with source-build (on RHEL 7 and RHEL 8).

[jkoritzinsky]

I've applied your patch. Marking this PR as ready for review/non-work in progress

[akoeplinger]

The non-coreclr specific changes look good to me (can't vouch for the coreclr changes).

[janvorli]

An idea for a future cleanup: This add_library / target_sources pair pattern is used at 24 places. It may be nice to clean this up in a follow up change by creating a cmake function for this pattern. Or even encapsulate the add_library_clr in that function, getting something along these lines:

add_intermediate_library_clr(bcltype${BCLTYPE_SOURCES})
add_intermediate_library_dependencies(bcltypeeventing_headers)

[jkoritzinsky]

Yes, we should clean this up in the future by making some additional functions.

[janvorli]

I wonder why was this change needed. Linking to the static libraries should work fine. The only case when we need to use object libraries is when a static library is built as a combination of other libraries, but it is not the case here.

[jkoritzinsky]

The libhostfxr_static and libhostpolicy_static targets are object libraries. The corehost CMake infra could really use some updates and cleanup to be more straightforward. I'd like to do that in a future PR.

[janvorli]

Hmm, interesting. I can see that they were changed to object ones few months ago and I am not sure why.

I agree that the corehost cmakefiles are very difficult to mentally parse. They looks as if msbuild style of build programming was used here. Instead of using functions for doing common stuff, ambient cmake variables are being set and then common helper cmake files included. I'd love to see it transformed to a natural cmake way at some point.

[jeffschwMSFT]

cc @mmitche

[jkoritzinsky]

@janvorli any more comments?

[janvorli]

LGTM, thank you!

[janvorli]

@jkoritzinsky no, I have thought I've already approved it, but I can see I haven't. So I've just done that.

[jashook]

Thank you @jkoritzinsky for driving this effort!

[jashook]

@omajid which version of clang are we using on redhat 7 for source build? We noticed that by default centos 7 installs 3.4 which we do not support building with.

/cc @janvorli@jkoritzinsky

[omajid]

which version of clang are we using on redhat 7 for source build?

We have generally used llvm-toolset-7.0-cmake (CentOS version here), which is 3.6.2.

This is how we are building 3.1 with llvm-toolset-7.0: https://git.centos.org/rpms/rh-dotnet31-dotnet/blob/c7-dotnet/f/SPECS/dotnet.spec#_314. I don't have a 5.0 version yet, because I haven't been able to build source-build there.

[jashook]

Clean builds using the following:

Os	Cmake	Clang/llvm
Centos 7	3.6.2	7
Centos 8	3.11.4	8

[mmitche]

@jeffschwMSFT Was this supposed to be ported to p8?

[jeffschwMSFT]

@mmitche yes, @jashook is working on the port.

[omajid]

I did a port to preview 4, so I could build against older cmake versions using source-build. Source-build is currently at 5.0 Preview 4. Port is available here: https://github.com/omajid/runtime/tree/5.0-preview4-cmake-backport