[s390x] Missing commit identifier in libcoreclr.so

[omajid]

The libcoreclr.so on s390x (which is actually mono) doesn't include a commit identifier, like other binaries, such as libSystem.native.so do.

$ strings /usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0-rc.2.21470.23/libSystem.Native.so | grep '@(#)'
@(#)Version 6.0.21.47023 @Commit: 826f81a11ad17f415668fe1cb934bdaf00d36ea2
$ strings /usr/lib64/dotnet/shared/Microsoft.NETCore.App/6.0.0-rc.2.21470.23/libcoreclr.so | grep '@(#)'

I guess this a build configuration difference in mono?

This is a source-build SDK:

$ /usr/lib64/dotnet/dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.100-rc.2.21474.1
 Commit:    28be3e9a00

Runtime Environment:
 OS Name:     rhel
 OS Version:  8
 OS Platform: Linux
 RID:         rhel.8-s390x
 Base Path:   /usr/lib64/dotnet/sdk/6.0.100-rc.2.21474.1/

Host (useful for support):
  Version: 6.0.0-rc.2.21470.23
  Commit:  826f81a11a

.NET SDKs installed:
  6.0.100-rc.2.21474.1 [/usr/lib64/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.0-rc.2.21470.37 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.0-rc.2.21470.23 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

cc @uweigand @BahaVv

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[uweigand]

So at a first glance, there does indeed appear to be a difference. For the coreclr directory, we get a file called ./obj/coreclr/Linux.s390x.Release/version.c which contains:

static char sccsid[] __attribute__((used)) = "@(#)Version 6.0.21.47023 @Commit: 826f81a11ad17f415668fe1cb934bdaf00d36ea2";

and is linked into the libcoreclr.so binary.

For the mono directory, we instead get a file called ./obj/mono/Linux.s390x.Release/_version.h which likewise contains:

static char sccsid[] __attribute__((used)) = "@(#)Version 6.0.21.47023 @Commit: 826f81a11ad17f415668fe1cb934bdaf00d36ea2";

but apparently is not linked directly linked into the binary (well, it's a header), and also not even included into any source file that gets linked into the binary (or any source file at all that I can see).

I'm not sure where this difference comes from, but I guess we could change mono to behave the same as coreclr (e.g. call the file version.c and link it in)?

However, as added complication, that version.c logic in coreclr is only used when building on a Unix host, not on Windows. Not sure what this is all about, and whether we'd have to do the same in Mono?

[uweigand]

CC @steveisok @directhex @akoeplinger

[uweigand]

However, as added complication, that version.c logic in coreclr is only used when building on a Unix host, not on Windows. Not sure what this is all about, and whether we'd have to do the same in Mono?

I see, on Windows we instead create a _version.h header file which is included into a resource file to define the version. This seems to be implemented already in Mono, so we'd need to keep this and just implement the sccsid version.c method for Linux targets.