Add images for cross-compiling against Ubuntu 18.04, not 16.04

[directhex]

There are cases where the 16.04 crossroot is too old, e.g. we cannot compile LLVM >16 because the libstdc++ version in Ubuntu 16.04 is too old. If we are careful in checking the versioned symbols consumed from libstdc++ and glibc, we can build against a newer base OS without significantly altering our supported base OS version (e.g. objwriter compiled against this image still supports every OS on the .NET 8.0 support matrix, and a few beyond it such as Amazon Linux 2.0).

x64 build is blocked on dotnet/arcade#13277

[sbomer]

This would be useful for dotnet/jitutils#370 as well.

[directhex]

This is failing because the cached crossdeps-builder Docker image is too old, right?

[directhex]

This is failing because the cached crossdeps-builder Docker image is too old, right?

root [ /home/directhex/Projects/dotnet-buildtools-prereqs-docker ]# ls /scripts/eng/common/cross/x64/sources.list.bionic 
ls: cannot access '/scripts/eng/common/cross/x64/sources.list.bionic': No such file or directory

Bingo.

[sbomer]

Yes, looks like it. Last time I hit a caching issue @mthalman suggested to make a no-op change to the Dockerfile whose cache you want to invalidate, for testing in ci. Then once it's green you can undo the no-op change and merge, and @mthalman will ensure it gets a non-cached build in offiacl ci. Does that sound right @mthalman?

[directhex]

Yes, looks like it. Last time I hit a caching issue @mthalman suggested to make a no-op change to the Dockerfile whose cache you want to invalidate, for testing in ci. Then once it's green you can undo the no-op change and merge, and @mthalman will ensure it gets a non-cached build in offiacl ci. Does that sound right @mthalman?

Sounds like last time I had to invalidate a low-level image (to add s390x or ppc64el or somesuch)

[directhex]

And I think GH is down. I'm getting failures on git push and trying to add comments to this PR. So sounds like I won't get this sorted today.

[mthalman]

Yes, looks like it. Last time I hit a caching issue @mthalman suggested to make a no-op change to the Dockerfile whose cache you want to invalidate, for testing in ci. Then once it's green you can undo the no-op change and merge, and @mthalman will ensure it gets a non-cached build in offiacl ci. Does that sound right @mthalman?

Yes. And actually, you might as well make the no-op change permanent. That will automatically invalidate the cache on the internal build too. So I would suggest just adding whitespace to the Dockerfile that needs to get rebuilt. Not pretty, I know.

[directhex]

Yes, looks like it. Last time I hit a caching issue @mthalman suggested to make a no-op change to the Dockerfile whose cache you want to invalidate, for testing in ci. Then once it's green you can undo the no-op change and merge, and @mthalman will ensure it gets a non-cached build in offiacl ci. Does that sound right @mthalman?

Yes. And actually, you might as well make the no-op change permanent. That will automatically invalidate the cache on the internal build too. So I would suggest just adding whitespace to the Dockerfile that needs to get rebuilt. Not pretty, I know.

Not even in the top 100 grossest hacks I'll have committed to disk during my career

[directhex]

Well it got there in only 5 hours

[sbomer]

LGTM, thank you!