-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify some cmake function definitions #33716
Conversation
@jkotas, this is ready for review. The no_tiered compilation test on OSX seems to be failing for quite some time (since Feburary): https://dev.azure.com/dnceng/public/_build/results?buildId=566314&view=ms.vss-test-web.build-test-results-tab&runId=17801042&resultId=100000&paneView=history. |
eng/native/configurecompiler.cmake
Outdated
@@ -467,10 +470,6 @@ if (MSVC) | |||
add_compile_options(/ZH:SHA_256) # use SHA256 for generating hashes of compiler processed source files. | |||
add_compile_options(/source-charset:utf-8) # Force MSVC to compile source as UTF-8. | |||
|
|||
if (CLR_CMAKE_HOST_ARCH_I386) | |||
add_compile_options(/Gz) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a problem with using /Gz
everywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With /Gz
in shared location, we get the following error in installer x86 build:
.\build.cmd -subsetcategory installer -arch x86
...
"C:\Users\adeel\Source\Repos\runtime2\artifacts\obj\win-x86.Debug\corehost\INSTALL.vcxproj" (rebuild target) (1) ->
"C:\Users\adeel\Source\Repos\runtime2\artifacts\obj\win-x86.Debug\corehost\ALL_BUILD.vcxproj" (default target) (3:2) ->
"C:\Users\adeel\Source\Repos\runtime2\artifacts\obj\win-x86.Debug\corehost\cli\comhost\comhost.vcxproj" (default target) (4:2) ->
C:\Users\adeel\Source\Repos\runtime2\src\installer\corehost\cli\fxr_resolver.h(83,1): error C2664: 'propagate_error_writer_t::propagate_error_writer_t(const propagate_error_writer_t &)': cannot convert argument 1 from 'hostfxr_set_error_writer_fn' to 'propagate_error_writer_t::set_error_writer_fn' (compiling source file C:\Users\adeel\Source\Repos\runtime2\src\installer\corehost\cli\comhost\comhost.cpp) [C:\Users\adeel\Source\Repos\runtime2\artifacts\obj\win-x86.Debug\corehost\cli\comhost\comhost.vcxproj]
I think it is because this function requires __cdecl
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, looks like some places are missing HOSTPOLICY_CALLTYPE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That also worked, now /Gz is back in shared location: 2264fa0. __cdecl
is defined as empty for other platforms in pal.h, so I just used __cdecl or HOSTPOLICY_CALLTYPE, whichever was available via included headers.
eng/native/configurecompiler.cmake
Outdated
@@ -18,7 +20,7 @@ include(${CMAKE_CURRENT_LIST_DIR}/configureoptimization.cmake) | |||
#----------------------------------------------------- | |||
|
|||
if(MSVC) | |||
add_compile_options(/Zi /FC /Zc:strictStrings) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happened to /Zc:strictStrings
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was causing an error in installer:
.\build.cmd -subsetcategory installer
fxr_resolver.cpp
6>C:\Users\adeel\Source\Repos\runtime2\src\installer\corehost\cli\hostmisc\pal.windows.cpp(230,51): error C2440: 'initializing': cannot convert from 'const unsigned short [18]' to 'pal::char_t *' [C:\Users\adeel\Source\Repos\runtime2\artifacts\obj\win-x64.Debug\corehost\cli\hostmisc\libhostmisc.vcxproj]
C:\Users\adeel\Source\Repos\runtime2\src\installer\corehost\cli\hostmisc\pal.windows.cpp(230,26): message : Conversion from string literal loses const qualifier (see /Zc:strictStrings) [C:\Users\adeel\Source\Repos\runtime2\artifacts\obj\win-x64.Debug\corehost\cli\hostmisc\libhostmisc.vcxproj]
longfile.windows.cpp
6>C:\Users\adeel\Source\Repos\runtime2\src\installer\corehost\cli\hostmisc\pal.windows.cpp(280,52): error C2440: '=': cannot convert from 'const unsigned short [18]' to 'pal::char_t *' [C:\Users\adeel\Source\Repos\runtime2\artifacts\obj\win-x64.Debug\corehost\cli\hostmisc\libhostmisc.vcxproj]
C:\Users\adeel\Source\Repos\runtime2\src\installer\corehost\cli\hostmisc\pal.windows.cpp(280,29): message : Conversion from string literal loses const qualifier (see /Zc:strictStrings) [C:\Users\adeel\Source\Repos\runtime2\artifacts\obj\win-x64.Debug\corehost\cli\hostmisc\libhostmisc.vcxproj]
I forgot to add it in CoreCLR, will do. Or maybe I should first try to make installer compatible with strictStrings
. 💭
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it would be nice to sprinkle const
as necessary to fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am running a clean Windows build on side, will get to this point soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using const
in few places fixed the build error withstrictStrings
: 4fc15c2. Thanks. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@janvorli @jkoritzinsky Any other comments?
@@ -289,6 +300,20 @@ function(strip_symbols targetName outputFilename skipStrip) | |||
endif(CLR_CMAKE_HOST_UNIX) | |||
endfunction() | |||
|
|||
function(install_symbols targetName destination_path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is weird that we always strip symbols for libraries and strip them conditionally for coreclr. Since you are touching this code, I would take this opportunity to make the stripping unconditional. It should be fine (debugging should not be affected, I believe neither lldb nor gdb cares whether the symbols are in the .so files or in separate files) and it would also fix #32957 on OSX where debugging a core dump from checked / debug build is currently broken due to missing symbols.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we start by removing the top-level option:
runtime/eng/native/build-commons.sh
Line 190 in 8db7154
echo "-stripsymbols: skip native image generation." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
II would do it in 3 steps in this order:
- Make stripping the symbols unconditional in the cmake files (essentially just ignore the
-stripsymbols
option as part of this PR - Remove passing in the
-stripsymbols
to the build scripts in the CI / build lab scripts in a follow up PR - Remove the
-stripsymbols
option support from thebuild-commons.sh
The point is that we don't want to have intermediate period where we would not be stripping the symbols and we also cannot pass in the -stripsymbols from the CI / build lab scripts after we remove support for that option from the build-commons.sh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part 1 is pushed f193079. I will make followup PRs for 2 and 3. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
Looks like OOM, known issue perhaps related to: #32377
|
dotnet#33716 set TARGET_DARWIN for iOS too but most of the logic is really OSX-specific. Unset TARGET_DARWIN for iOS and rename the rest of the occurrences to TARGET_OSX.
#33716 set TARGET_DARWIN for iOS too but most of the logic is really OSX-specific. Unset TARGET_DARWIN for iOS and rename the rest of the occurrences to TARGET_OSX.
Also cleaned up usage of remaining
_TARGET_*
in favorTARGET_*
macros.