Bug: Publish optimization uses a hardcoded runtime linux-x64 again.

[derwasp]

Description

I fixed this issue 2 years ago(#26), and now it seems like it's back. Starting with #112 the linux-x64 moniker is used instead of the rhel.7.2-x64. While rhel.7.2-x64 was not the perfect choice for the runtime, internet says that rhel is in general quite compatible with amazon linux. And that rhel7 and amazon linux 2 are pretty close. And this mention was in the code, but was removed here.

This time the bug is pretty sneaky, as for me everything broke after I updated to netcoreapp3.1. Now there's a switch that selects the moniker here and it works fine for the previous versions, while for netcoreapp3.1 (well anything other than 1.0, 2.0 and 2.1) it selects linux-x64 and my app stops working.

The issue is the same for me as it was before. But this time not only for me, you can see @boemekeld posting about it here and here.
My experience shows that most of the time linux-x64 means ubuntu/debian distros and not rhel/centos/amazonlinux. Static linking will probably solve the issue, but so far I don't see library developers doing it (and they have reasons for this). So in my eyes, it's still reasonable to do best effort compatibility instead of asking users to build workarounds like @ashishdhingra suggested in his response to @boemekeld.
@boemekeld also said that rhel worked just fine for him. I didn't re-test it, but I imagine that this would be the case, like with the old version.

@normj what was the reason to change the behavior? Can you please make it work again?

Reproduction Steps

See @boemekeld's ticket here.

Logs

See @boemekeld's ticket here.

Environment

• Build Version: 4.1.0
• OS Info: AmazonLinux
• Build Environment: CodeBuild's Ubuntu standard 4.0
• Targeted .NET Platform: AnyCPU

Resolution

• 👋 I can/would-like-to implement a fix for this problem myself

Well, I can remove the switch, like so: #137

---

This is a 🐛 bug-report

[derwasp]

I tweaked my test a bit (added multi-targeting to the project and updated the aws json lib) so it works with the new library, and as expected, got a failure for the new version, but not for the old one:

[derwasp]

These are the changes that I made to the test: bd8b906

[boemekeld]

Thanks for that @derwasp

[normj]

Sorry this change messed up your packaging. I made the change for 3.1 to use linux-x64 because it seemed like that is what the .NET team at Microsoft has been trying to push people to use and using the rhel.7.2-x64 RID always seemed like a bit of a lie. Also Lambda 3.1 runs on Amazon Linux 2 which as I understand varies more then Amazon Linux from rhel.

I would rather keep the linux-x64 but I wonder if I updated the deployment code to inspect the --msbuild-parameters switch and if it was specially setting the runtime then don't override it with linux-x64. That would give you a workaround where you could just set the runtime in your aws-lambda-tools-defaults.json file. Would that be acceptable?

[derwasp]

Hey @normj, thanks for the response.
I agree that rhel.7.2-x64 seems a bit alien in this case. However, looking at a virtual machine running Amazon Linux 2, you can see this:

First of all we can look at cat /etc/os-release and see that this distro is "like" centos/rhel/fedora:

[ec2-user@ip-xxx-xx-xxx-xxx ~]$ cat /etc/os-release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"

Then we can also look at this and see which RHEL RPM repos the distro is using, and it says that it's version 7:

[ec2-user@ip-xxx-xx-xxx-xxx ~]$ rpm -E %{rhel}
7

And then we can look here and see which version of Red Hat the distro is based on:

[ec2-user@ip-xxx-xx-xxx-xxx ~]$ cat /proc/version
Linux version 4.14.193-149.317.amzn2.x86_64 (mockbuild@ip-10-0-1-32) (gcc version 7.3.1 20180712 (Red Hat 7.3.1-9) (GCC)) #1 SMP Thu Sep 3 19:04:44 UTC 2020

And as you can see, it appears to be Red Hat 7.

As for the suggestions to use linux-x64 instead of rhel I was only able to find the mention here (link pinned to master at the moment of publication), where the documentation says that rhel-x64 was superseded by linux-x64, but they don't mention rhel.7.2-x64. Not sure if it makes any difference though.
Can you point me somewhere to read about linux-x64 being the recommended choice? Because probably I am missing something here. I thought that the idea behind RIDs is to actually target specific platforms. And when an application has platform-specific binaries, there's a chance that if it's targeting the wrong distro type, it will not work. And the reason for that (as far as I know) is that the package distribution is different across different types of distros. And this seems to be not the case for us here: rhel7 and amzn2 appear to be using the same stuff. While the .net runtime can have their binaries platform-independent, it doesn't mean that the 3rd party dependencies will also do this (via static linking I assume?).

As I can see folks from MS are actively maintaining the hierarchy list in the runtime repository. And it seems like they accept pullrequests for new/updated RIDs. Maybe this should be the way forward?

Despite all this, I am open to other options as long as they will fix the issue in question. It's just that I don't see a good reason not to use the rhel RID, while it seems to be very-very compatible. And it's definitely more compatible that the generic linux-x64.

I am by no means an expert in Linux, but I am just trying to get to the bottom of it and understand how things work.

Regardless of the discussion, the idea you are suggesting (allow to override the RID) sounds like a good one anyway, so I'd say let's do it.

[github-actions]

We have noticed this issue has not received attention in 1 year. We will close this issue for now. If you think this is in error, please feel free to comment and reopen the issue.