Skip to content
Snippets Groups Projects
Commit 8ed8ac58 authored by Austin Seipp's avatar Austin Seipp
Browse files

Hackishly fix parallel build failure with in-tree GMP


See the comments and #8102. The basic gist of it seems to be that the
build system follows an implied rule from somewhere to directly build a
C file, which doesn't have a dependency on the in-tree gmp.h that we
build. As a result, the C file compilation races against the GMP build,
causing an error.

This is a pretty unsatisfactory hack, but for Windows and OS X machines
where we more often build in-tree GMPs, it's quite important.

Authored-by: default avatarKazu Yamamoto <kazu@iij.ad.jp>
Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
parent 8bf95419
No related branches found
No related tags found
No related merge requests found
......@@ -26,7 +26,14 @@ $(GmpDerivedConstants_HEADER): $(mkGmpDerivedConstants_INPLACE)
ifneq "$(HaveLibGmp)" "YES"
ifneq "$(HaveFrameworkGMP)" "YES"
$(libraries/integer-gmp/mkGmpDerivedConstants_dist_depfile_c_asm): libraries/integer-gmp/gmp/gmp.h
# NOTE: we should really be referring to the depfile generated by the build
# system here, but due to an awkward contortion I can't figure out, the build
# system follows an implied from somewhere else to directly build the C file
# instead (independent of the depfile rules), which doesn't have a built gmp.h
# dependency. This race causes the parallel build to fail.
#
# See #8102
libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c: libraries/integer-gmp/gmp/gmp.h
endif
endif
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment