[mono] Fix libcoreclr.so build incompatibilities on Linux

[uweigand]

• Link with -z relro -z now to enable full RELRO mode
  Fixes[s390x] Missing full RELRO (-z,now) support in a mono-based libcoreclr.so #59904

• Generate and link in version.c to provide version string
  Fixes[s390x] Missing commit identifier in libcoreclr.so source-build#2484

This makes the Mono build of libcoreclr.so on Linux look like the CoreCLR build w.r.t. these two issues.

[akoeplinger]

can we make this consistent with Android:

Suggested change

	add_link_options(-Wl,-z,relro,-z,now)
	add_compile_options(-Wl,-z,now)
	add_compile_options(-Wl,-z,relro)

... and what about noexecstack?

[akoeplinger]

ah I just saw #59987 (comment) and you tried that already. it's interesting why this doesn't work on Linux, can you please still split it into different lines and leave a comment about why add_link_options is used?

[uweigand]

The "add_compile_options" didn't actually work for me - it is not being applied at the final link step, which is actually the only step where it really matters.

As to noexecstack, the library is already marked as noexecstack to me. That's to be expected as the compilers already mark objects files they generate accordingly. The only reason for a manual override is when you link in a full assembler file (.s), which I don't believe happens in the Mono build.

[uweigand]

Sorry, didn't see the latest comment. I'm actually a bit surprised that add_compile_options works for Android, I would have expected the same problem (I can't really test that here). If you prefer two lines, I can certainly change that, I just used what was in eng/native/configurecompiler.cmake ...

[uweigand]

Added comment and split back into two lines. Let me know if there's anything else you'd like me to do. Thanks!

[akoeplinger]

Thanks, looks good now. We can probably change Android to use add_link_options too, I suppose add_compile_options works because we use clang there.

[akoeplinger]

@uweigand looks like there's an issue in the AOT cross compiler build on Windows:

 D:\workspace\_work\1\s\artifacts\obj\mono\Android.x64.Release\cross\NativeVersion.rc(6) : error RC2104 : undefined keyword or key name: VER_FILEVERSION

[uweigand]

@uweigand looks like there's an issue in the AOT cross compiler build on Windows:

 D:\workspace\_work\1\s\artifacts\obj\mono\Android.x64.Release\cross\NativeVersion.rc(6) : error RC2104 : undefined keyword or key name: VER_FILEVERSION

Ah, right. Looks like this needs to check $(OS) instead of $(TargetOS). I'll fix.

[uweigand]

The Browser_wasm_Windows failure looks related:

2021-10-05T16:38:59.7309497Z CMake Error at mono/mini/CMakeLists.txt:326 (add_library):
2021-10-05T16:38:59.7310657Z Cannot find source file:
2021-10-05T16:38:59.7312737Z 2021-10-05T16:38:59.7313609Z D:/workspace/_work/1/s/artifacts/obj/mono/Browser.wasm.Release/version.c

So I think this is yet another case, where we're cross-building a version of the runtime hosted on Wasm, right? We don't get a version.c because in this case $(OS) == 'Windows_NT'. And it's challenging to get a version.c because the GenerateNativeVersionFile target in arcade uses the same $(OS) == 'Windows_NT' check and would create the Windows version header contents anyway.

Also, it's not clear that using an embedded sccsid string would even work for a wasm/emscripten binary ... Should we just keep not doing any version string in the HOST_BROWSER case then?

[uweigand]

The Browser_wasm_Windows failure looks related:

2021-10-05T16:38:59.7309497Z CMake Error at mono/mini/CMakeLists.txt:326 (add_library):
2021-10-05T16:38:59.7310657Z Cannot find source file:
2021-10-05T16:38:59.7312737Z 2021-10-05T16:38:59.7313609Z D:/workspace/_work/1/s/artifacts/obj/mono/Browser.wasm.Release/version.c

So I think this is yet another case, where we're cross-building a version of the runtime hosted on Wasm, right? We don't get a version.c because in this case $(OS) == 'Windows_NT'. And it's challenging to get a version.c because the GenerateNativeVersionFile target in arcade uses the same $(OS) == 'Windows_NT' check and would create the Windows version header contents anyway.

Also, it's not clear that using an embedded sccsid string would even work for a wasm/emscripten binary ... Should we just keep not doing any version string in the HOST_BROWSER case then?

Disabled this for now, can be changes again later once it's clear what to do.

[akoeplinger]

Disabled this for now, can be changes again later once it's clear what to do.

Sounds good to me, thanks!

[uweigand]

Thanks @akoeplinger ! Can still this get included into .NET 6 at this point? This would help the RHEL builds.

[akoeplinger]

/backport to release/6.0

[github-actions]

Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1313127365