ICU-23247 BRS 78: Bump the runs-on value of all GitHub workflows to the current versioned values corresponding to -latest

[eggrobin]

Checklist

• Required: Issue filed: ICU-23247
• Required: The PR title must be prefixed with a JIRA Issue number. Example: "ICU-NNNNN Fix xyz"
• Required: Each commit message must be prefixed with a JIRA Issue number. Example: "ICU-NNNNN Fix xyz"
• Issue accepted (done by Technical Committee after discussion)
• Tests included, if applicable
• API docs and/or User Guide docs changed or added, if applicable
• Approver: Feel free to merge on my behalf

[markusicu]

changes lgtm, but several CI checks fail :-(

[markusicu]

At a glance, looks like different checks have different failures. Docs build: I see warnings, not failures. depstest on one bot is completely broken. Windows SDK missing. etc.

Maybe @richgillam + @roubert or other team members can help.

[markusicu]

@eggrobin @richgillam @roubert please take a look at the CI failures -- see my comments above.

[richgillam]

I don't know why icu4c-docs-build is failing; all I see in the log are warnings.

clang-release-build-and-test has TONS of errors, all of which look like this...

Error: in group platform: common/fixedstring.o imports icu_79::UnicodeString::extract(int, int, char*, int, icu_79::UnicodeString::EInvariant) const - is this a new system symbol?

...but complaining about different symbols in UnicodeString. That one seems legit.

In clang-options-build-and-test (--enable-statis --disable-shared), we have a ton of link errors, also all having to do with various methods on UnicodeString.

In -gcc10-stdlib17, configure failed with this error:

checking whether the C compiler works... no
configure: error: in '/home/runner/work/icu/icu/build':
configure: error: C compiler cannot create executables

And in windows-mdvc (arm Release) and windows-msvc-dist-release, we got this:

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 10.0.22621.0 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [D:\a\icu\icu\icu4c\source\stubdata\stubdata.vcxproj]

So the errors all look legit to me...

[markusicu]

So the errors all look legit to me...

Except that the updates in this PR are just moving to the next stable versions of Ubuntu and the OSes, and we have already been testing with some newer, non-default compilers.

Maybe @eggrobin can rebase to the lastest main and see if CI improves?

[roubert]

Maybe @eggrobin can rebase to the lastest main and see if CI improves?

That doesn't seem like a bad plan at all. I've tried building this PR on my own machine, using the same configurations as in the log files from the failing CI jobs but it works just fine when I do it, so it seems likely that whatever is wrong here it isn't actually our code but something on the CI.

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[markusicu]

six build bots are still failing :-(

[roubert]

six build bots are still failing :-(

I think I've now found something there, take a look at this particular error message (which appears repeatedly in the log file of the failed clang-options-build-and-test):

bfd plugin: LLVM gold plugin has failed to create LTO module: Unknown attribute kind (91) (Producer: 'LLVM18.1.3' Reader: 'LLVM 17.0.6')

Notice how the two version numbers differ there. That can't be right, the entire toolchain ought to be of the same version, I can imagine that his could cause all sorts of problems.

[roubert]

bfd plugin: LLVM gold plugin has failed to create LTO module: Unknown attribute kind (91) (Producer: 'LLVM18.1.3' Reader: 'LLVM 17.0.6')

These errors seem to originate from ar and I don't have the faintest idea about what version of ar runs by default in the ubuntu-24.04 image in the GitHub CI, but instead of trying to find that out a possible workaround could instead be to just override the version used by setting AR='llvm-ar-18' & RANLIB='llvm-ranlib-18'. (Even if that ends up not working, knowing exactly what version is being used might give some useful clue as to where the version mismatch originates.)