Building 3.0 on Arch Linux

[alucryd]

Reopening an issue since for some reason issue #1242 was completely nuked along with all the valuable information it contained.

The latest head of the release/3.0 branch still doesn't build. Did you guys make progress on this?

[omajid]

issue #1242 was completely nuked

Yikes. I can't seem to access it either. @dleeapho Any chance we could get that issue back?

Did you guys make progress on this?

I tried installing Arch on a machine, but I didn't have much luck. Tried it in a container and I ran into the dreaded "too many files open" issue :(

Can you git clone https://github.com/dotnet/source-build --recrusive and make this change:

diff --git a/tools-local/arcade-services/eng/Versions.props b/tools-local/arcade-services/eng/Versions.props
index c69a2ff..6350ff1 100644
--- a/tools-local/arcade-services/eng/Versions.props
+++ b/tools-local/arcade-services/eng/Versions.props
@@ -12,7 +12,7 @@
     <CommandLineParserVersion>2.2.1</CommandLineParserVersion>
     <CredentialManagementVersion>1.0.2</CredentialManagementVersion>
     <HandlebarsNetVersion>1.9.5</HandlebarsNetVersion>
-    <LibGit2SharpVersion>0.26.0</LibGit2SharpVersion>
+    <LibGit2SharpVersion>0.27.0-preview-0020</LibGit2SharpVersion>
     <log4netVersion>2.0.8</log4netVersion>
     <SystemNetHttpVersion>4.3.3</SystemNetHttpVersion>
     <MicrosoftAzureKeyVaultVersion>3.0.3</MicrosoftAzureKeyVaultVersion>

And try a ./build.sh?

I also opened dotnet/corefx#41750 and dotnet/cli#12880

[alucryd]

@omajid Thanks for the PRs!

What's this newer libgit2 for? The current one works fine with openssl 1.0 installed, is 0.27.0 built with openssl 1.1?

[robinchew]

Here's a Google cache of #1242 https://webcache.googleusercontent.com/search?q=cache:CIeT58k-DkgJ:https://github.com/dotnet/source-build/issues/1242 and I've also attached a screenshot.
https://user-images.githubusercontent.com/7122710/66716574-d7897a80-ee01-11e9-8ea8-79f5b8a10c6d.png

[omajid]

is 0.27.0 built with openssl 1.1

Kind of; 0.27 is more flexible and supports both.

[alucryd]

Kind of; 0.27 is more flexible and supports both.

Works like a charm with just openssl 1.1 in the chroot, thanks!

[omajid]

Works like a charm with just openssl 1.1 in the chroot, thanks!

Does that mean you can build .NET Core 3.0 in the chroot? Or that it gets you past libgit2 erorrs?

[alucryd]

Just the libgit2 errors, those were previously fixed by having openssl 1.0 in the chroot, but now it works with 1.1, hopefully we can start retiring 1.0 from our repos soon.

[adaggarwal]

Reopening an issue since for some reason issue #1242 was completely nuked along with all the valuable information it contained.

The latest head of the release/3.0 branch still doesn't build. Did you guys make progress on this?

I think it didn't transfer cleanly. Here's the original issue - https://github.com/dotnet/core-eng/issues/7996

Here is the coreFX reference to this issue.

cc: @alucryd @omajid

[omajid]

I think it didn't transfer cleanly. Here's the original issue - dotnet/core-eng#7996

Unfortunately, dotnet/core-eng is, as far as I know, restricted to folks inside Microsoft. As an outsider-to-Microsoft, the optic of this change look like kicking the community out from a community-based issue. I know that's probably not intentional on anyone's part. Is there any chance we could get the issue back in a place everyone can see it?

I can see the corefx issue, but it just contains a pointer to the can't-be-seen-core-eng-issue.

[adaggarwal]

I think it didn't transfer cleanly. Here's the original issue - dotnet/core-eng#7996

Unfortunately, dotnet/core-eng is, as far as I know, restricted to folks inside Microsoft. As an outsider-to-Microsoft, this change looks like someone just completely restricted/hid the issue :(

I can see the corefx issue, but it just contains a pointer to the can't-be-seen-core-eng-issue.

Ah. I understand now. I tried to get the issue back. But it wasn't very consistent. Using zenhub, I could get all the comments and timestamps. It just lacks the reactions. I hope we can reference #1312 for history.

[dagood]

FYI, I found this in the help doc for GitHub transfers:

You can't transfer an issue from a private repository to a public repository.

I guess it makes sense from a "make it a little harder to expose secrets" sense, but unfortunate for this case. Would have been nice to be able to use the "native" move to bring it back as-was.

[omajid]

I have now locally seen both arch-x64 and fedora.32-x64 builds fail with failures similar to:

    chmod +x /builddir/build/BUILD/dotnet-v3.0.0/src/corefx.4ac4c0367003fe3973a3648eb0715ddb0e3bbcea/artifacts/bin/testhost/netcoreapp-Linux-Release-x64/                                                                        
    chmod: cannot access '/builddir/build/BUILD/dotnet-v3.0.0/src/corefx.4ac4c0367003fe3973a3648eb0715ddb0e3bbcea/artifacts/bin/testhost/netcoreapp-Linux-Release-x64/': No such file or directory                               
8>/builddir/build/BUILD/dotnet-v3.0.0/src/corefx.4ac4c0367003fe3973a3648eb0715ddb0e3bbcea/external/runtime/runtime.depproj(63,5): error MSB3073: The command "chmod +x /builddir/build/BUILD/dotnet-v3.0.0/src/corefx.4ac4c0367003fe3973a3648eb0715ddb0e3bbcea/artifacts/bin/testhost/netcoreapp-Linux-Release-x64/" exited with code 1.     

Need to debug this some more.

Edit: I tried building on Fedora 30 (where this is known to work) with /etc/os-release modified to say 32. The build failed there with this exact same error. I doubt it's an issue in the system libraries or tools; otherwise it would have built on this hacked-Fedora-30 system too. This error seems more of an RID issue to me now.

[tmds]

This error seems more of an RID issue to me now.

It think like the issue is with:

<RuntimeIdentifier>$(PackageRID)</RuntimeIdentifier>

in runtime.depproj. I think it fails to restore some things when the rid is not known, causing them to be missing when they are used later (with the chmod).