-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update coredistools #370
Update coredistools #370
Conversation
af8c04a
to
d07dbed
Compare
Looks like the linux built llvm-tblgen on ubuntu-20.04 doesn't correctly run on ubuntu-20.04 for linux-x64 coredistools build (crashes? hangs?). It also fails to run at all, due to libraries dependencies, on the Linux arm/arm64 cross-build Docker containers. Probably would be best to abandon trying to use ubuntu at all, and try to get Mariner to work. Maybe after Mariner is updated to LLVM 16. |
I'm currently getting this when building locally (under Mariner linux-x64 container):
|
3db2b80
to
6ebbfad
Compare
6ebbfad
to
0c1a1ea
Compare
Looks like we still fail to build LLVM tblgen for LLVM 16.0.6 due to the same libstdc++ version issue when building under CBL-Mariner (mcr.microsoft.com/dotnet-buildtools/prereqs:cbl-mariner-2.0-cross-amd64):
Looks like /crossrootfs/x64 has libstdc++.so.6?
@sbomer Does this make sense? Are the Mariner images going to get an updated libstdc++ version 7 sometime? Any other suggestion? cc @jakobbotsch |
Those images have an old ubuntu rootfs that we target in our official builds for broad compatibility with a large range of glibc versions, and they don't have libstdc++ 7 installed or available in the repos. @directhex ran into this too, and created images specifically to solve this problem, which have a newer rootfs (Ubuntu 18.04 instead of 16.04): dotnet/dotnet-buildtools-prereqs-docker#857. I would try using those images instead (for example, mcr.microsoft.com/dotnet-buildtools/prereqs:cbl-mariner-2.0-cross-ubuntu-18.04-amd64). cc @directhex in case you have any advice. |
For .NET 9, you can use a newer crossroot as @sbomer suggests. We no longer target Ubuntu 16.04 for .NET 9, but AFAIK our build images haven't been updated to reflect it yet. For .NET 8, you need to bring your own better c++ library. LLVM comes with one, you can either build it yourself or consume it via an LLVM nuget, then bundle it & fix up the |
I don't think I need to worry about .NET 8, so I'll try the new images. Thanks! |
Well, the new containers allowed the build to succeed, but now there is some missing or mis-versioned dependency:
|
Ah, it looks like the 18.04 rootfs had |
Maybe that worked? Now I get:
but it does seem to run. |
I tried to add a step to install libtinfo.so.5 to the docker container before llvm-tblgen is run, but got a permissions problem:
Maybe need to add it to the docker container construction for these? Or maybe there's some other permissions magic that will make it work? |
Try
|
Will try. Otherwise, looks like adding dotnet/dotnet-buildtools-prereqs-docker : src\cbl-mariner\2.0\crossdeps-builder\Dockerfile is the place to add it? |
https://github.com/dotnet/dotnet-buildtools-prereqs-docker/blob/fc0853cbd2ab042fcaa762b90759092336a2b9f3/src/cbl-mariner/2.0/crossdeps/Dockerfile would be the place to add it. I was a little hesitant to recommend this since we try to keep the build images pretty minimal, but I see we already added pip3 and zlib - so it probably doesn't hurt. |
Let's just get rid of the 18.04 images? The baseline for net9 is 20.04 isn't it? Bump the docker images to do that instead of 18.04, then you get the 6 SONAME for tinfo |
Maybe? I don't understand the Linux versioning rules. Note that dotnet/runtime#86194 moved all (or, at least most) CI VMs to 22.04. So maybe update to 22.04? |
Installing ncurses-compat using sudo worked. However, now the Linux x64 and arm64 builds (
at almost exactly 29 minutes. But the Linux arm one succeeds after just 6 minutes. Don't know what to do about it: there's no further info. |
Not sure about the latest failure - let's retry.
Good point, I just checked with @richlander and that's right. edit: see dotnet/runtime#91826 for details.
We build against a lower version (for broad glibc compat) than the version we run on in ci. So we would update the mariner build images to have a 20.04 rootfs, which will have libtinfo.so.6. |
Same result: builds cancelled at 27m 32s. https://dev.azure.com/dnceng-public/public/_build/results?buildId=400328&view=results |
Looks like there were some similar failures on OSX in the past: dotnet/runtime#34647. Could the build be filling up the disk? |
Maybe? These aren't OSX machines, though. I could add a "df -H" job to see the "before" state, but that wouldn't actually help if the cmake/llvm build itself is going crazy. I'll try again locally (on WSL2) but It's worked for me recently. |
1. LLVM doesn't release a full set of binary drops, so we need to build llvm-tblgen on some platforms, namely Mac. 2. Build using standard CBL-Mariner Docker containers (used by dotnet/runtime as well). This also converts linux-x64 builds to be container-based cross builds.
Also, fix one compilation bug to build coredistools.cpp with LLVM 16.0.1.
To use this in dotnet/runtime, after the package is published, `MicrosoftNETCoreCoreDisToolsVersion` in eng/Versions.props needs to be updated.
c52ab2f
to
4dfebad
Compare
Output more diagnostics on Linux build-coredistools build Update documentation for building Linux
The matrix appends the architecture to the displayName automatically. Remove some debugging output.
When coredistools is updated, dotnet/runtime#91668 should be reverted. |
Current status:
When this happens, there is no log file output. (It says If you watch the job, you can capture the in-progress build. linux-x64 seems to hang here:
and linux-arm64 hangs here:
|
@dotnet/jit-contrib This is ready to be reviewed and merged. The CI system is still failing to build the linux-arm64 and linux-x64 versions. It seems to hang at some point. I can build them fine, using the exact same CBL-Mariner docker containers and scripts, in my WSL2 Ubuntu 22.04.3 LTS OS. So I'm mystified as to the reason. If anyone has experience debugging the LLVM build process and AzDO builds, feel free to investigate. I built a new coredistools nuget package using all the successfully built components in the CI, plus linux-arm64 and linux-x64 built on my machine. |
1. Update header file to have type definitions for all DLL exported functions. 2. Remove unnecessary x86 instruction prefix handling (it was working around a bug that is apparently fixed). 3. Remove coredistools special handling of movw/movt. Instead, add a hopefully more general mechanism where cordistools will optionally first call a "munger" function on constants. This callback in the superpmi NearDiffer for arm32 will decode the movw/movt and treat the constructed constant as being generated by one instruction. This can also be used by arm64 mov/movk/movk/movk, although we currently don't have a need for that.
Looks like at least `lock` is still not treated as part of the instruction that follows it.
@jakobbotsch @dotnet/jit-contrib PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for doing this work!
Almost 9 months to get this in :-) Unfortunately, linux-x64 and linux-arm64 builds in the CI still hang (or otherwise fail). However, they succeed when built using the same Docker build containers on my Ubuntu 22.04 WSL2 host, so that's what I used to build the 1.4.0 coredistools package. It would still be nice to fix the CI if we could figure out how to debug the problem. |
TO DO:
Fixes #372