Skip to content
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

Run "git init" when .git doesn't exist to help GitHub source zip/tar.gz builds #1695

Merged
merged 1 commit into from
Aug 5, 2020

Conversation

@asbjornu
Copy link
Member

asbjornu commented Aug 5, 2020

Thanks for this, @dagood! My local test just finished and it unfortunately failed:

  [  8%] Linking CXX static library libcoreclrpal.a
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libcoreclrpal.a(context.S.o) has no symbols
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libcoreclrpal.a(context.S.o) has no symbols
  [  8%] Built target coreclrpal
  make: *** [all] Error 2
  Failed to build CoreCLR component.

  'coreclr' failed during build.
  See '/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/logs/coreclr.log' for more information.
  'corefx' failed during build.
  'msbuild' failed during build.
  'known-good' failed during build.

Build FAILED.

/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/packages/restored/microsoft.dotnet.arcade.sdk/1.0.0-beta.19359.6/tools/ProjectLayout.props(8,3): warning MSB4011: "/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/packages/restored/microsoft.dotnet.arcade.sdk/1.0.0-beta.19359.6/tools/RepoLayout.props" cannot be imported again. It was already imported at "/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/packages/restored/microsoft.dotnet.arcade.sdk/1.0.0-beta.19359.6/tools/Build.proj (52,3)". This is most likely a build authoring error. This subsequent import will be ignored.
/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/repos/Directory.Build.targets(262,5): error MSB3073: The command "/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/src/coreclr.018cfd06dceb19b6eb1e9217a500fb1071946fcd//build.sh x64 Release skiptests -ignoreWarnings -skipmanagedtools -skiprestore -nopgooptimize msbuildonunsupportedplatform cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE /bl /p:ILLinkTrimAssembly=false /p:CheckCDefines=false /p:PackagesDir=/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/packages/restored/ /p:ContinuousIntegrationBuild=true /p:VersionSuffix="servicing" -warnAsError:0 /v:minimal  /p:DotNetPackageVersionPropsPath=/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/obj/x64/Release/PackageVersions.props /p:DotNetRestoreSourcePropsPath=/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/obj/x64/Release/RestoreSources.props >> /private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/logs/coreclr.log 2>&1" exited with code 1. [/private/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/repos/coreclr.proj]
    1 Warning(s)
    1 Error(s)

Time Elapsed 00:56:05.92
Build failed (exit code '1').

Here's the contents of coreclr.log.

@dagood
Copy link
Member Author

dagood commented Aug 5, 2020

Thanks for giving it a shot. The first error in the log is:

[  0%] Building C object src/corefx/System.Globalization.Native/CMakeFiles/System.Globalization.Native_Static.dir/pal_calendarData.c.o
In file included from /tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/src/coreclr.018cfd06dceb19b6eb1e9217a500fb1071946fcd/src/corefx/System.Globalization.Native/pal_calendarData.c:10:
In file included from /tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/src/coreclr.018cfd06dceb19b6eb1e9217a500fb1071946fcd/src/corefx/System.Globalization.Native/pal_calendarData.h:8:
In file included from /tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/src/coreclr.018cfd06dceb19b6eb1e9217a500fb1071946fcd/src/corefx/System.Globalization.Native/pal_locale.h:5:
/tmp/dotnet-20200805-91052-50bno3/source-build-49195585d0de06e9a06b8fb005c460035363b2af/artifacts/src/coreclr.018cfd06dceb19b6eb1e9217a500fb1071946fcd/src/corefx/System.Globalization.Native/pal_icushim.h:19:10: fatal error: 'unicode/ucurr.h' file not found
#include <unicode/ucurr.h>
         ^~~~~~~~~~~~~~~~~

Have you gone through the CoreCLR setup instructions, for ICU in particular? Seems like a missing ICU header:
https://github.com/dotnet/coreclr/blob/release/3.1/Documentation/building/osx-instructions.md
or I guess https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/osx-instructions.md

As a heads up, you might also have a problem if you're trying to build on macOS 11/Big Sur, we aren't able to build there yet. dotnet/runtime#39900 fixes it in a CoreCLR branch but hasn't made it to a release yet.

Also, our macOS PR validation isn't working right now, tracked by #1685. I'll be ignoring it to merge this PR. I think it only takes the recent homebrew cmake update to break it. It shows up later (when trying to run) so I don't think that would have caused this compile error. More info at dotnet/runtime#39833.

All of the above isn't source-build related though--I'd suggest trying to build CoreCLR on its own and filing issues on dotnet/runtime to get in contact with the experts.

@dagood dagood merged commit 3b7e22f into dotnet:release/3.1 Aug 5, 2020
@dagood dagood deleted the git-init-if-empty branch August 5, 2020 15:00
@asbjornu
Copy link
Member

asbjornu commented Aug 5, 2020

Have you gone through the CoreCLR setup instructions, for ICU in particular? Seems like a missing ICU header:
https://github.com/dotnet/coreclr/blob/release/3.1/Documentation/building/osx-instructions.md
or I guess https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/osx-instructions.md

No, I haven't. Thanks, I'll try to add depends_on "icu4c" => :build and depends_on "pkg-config" => :build to the formula. Hopefully that helps.

As a heads up, you might also have a problem if you're trying to build on macOS 11/Big Sur, we aren't able to build there yet. dotnet/runtime#39900 fixes it in a CoreCLR branch but hasn't made it to a release yet.

I'm building on macOS Mojave 10.14.6, so that shouldn't be a problem.

Also, our macOS PR validation isn't working right now, tracked by #1685. I'll be ignoring it to merge this PR. I think it only takes the recent homebrew cmake update to break it. It shows up later (when trying to run) so I don't think that would have caused this compile error. More info at dotnet/runtime#39833.

Interesting. I've declared depends_on "cmake" => :build in the Homebrew formula, so perhaps that's going to break the same way here, then. We'll see.

All of the above isn't source-build related though--I'd suggest trying to build CoreCLR on its own and filing issues on dotnet/runtime to get in contact with the experts.

Thanks. That makes me think: Is a more modular approach to this perhaps better? I'm now trying to add a dotnet formula that does and contains "everything", but perhaps I should start at a lower level and add a dotnet-coreclr formula first, then build on that stepwise until we get a dotnet-sdk formula in working order?

Thoughts?

@dagood
Copy link
Member Author

dagood commented Aug 5, 2020

Thanks. That makes me think: Is a more modular approach to this perhaps better? I'm now trying to add a dotnet formula that does and contains "everything", but perhaps I should start at a lower level and add a dotnet-coreclr formula first, then build on that stepwise until we get a dotnet-sdk formula in working order?

Unfortunately there's no reasonable way in 2.1/3.1 to transport the outputs from one step to the next if built solo. No incrementality in other ways either. But CoreCLR is the roughest in terms of prereqs, so I don't think there's a need to do anything drastic here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants