The hashes for libc++ and libc++abi were wrong.
There was also an incompatibility with nixpkgs on darwin which is now
weakly worked around: the "os_trace" macro changed definition in the OS
X development SDK since version 10.9 as used by nixpkgs. LLVM 3.8 uses
the new version, which I am temporarily replacing with a printf on
darwin as it is only used in one minor location.
This allows us to remove a hack in the makefile, fixes a few bugs, and
also catches another edge case in the configure scripts.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The go tests get tripped up due to error messages along the lines of:
ld: warning: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation, ignoring unexpected dylib file
Which is due to us passing that along via $NIX_LDFLAGS in the `clang` wrapper.
To keep `go` from getting confused, I create a small `clang` wrapper that
filters out that warning.
Also, the strip.patch is no longer necessary, and only causes problems when
testing DWARF support:
--- FAIL: TestDwarfAranges (0.59s)
runtime-lldb_test.go:218: Missing aranges section
FAIL
FAIL runtime 17.123s
Also, I disable the misc/cgo/errors test, as I suspect it is also due to similar
problems regarding `ld`:
##### ../misc/cgo/errors
misc/cgo/errors/test.bash: BUG: expected error output to contain "err1.go:11:" but saw:
# command-line-arguments
cannot parse gcc output $WORK/command-line-arguments/_obj//_cgo_.o as ELF, Mach-O, PE object
2016/05/07 02:07:58 Failed: exit status 1
Closes#14208
The Chez build was failing, as usual, due to impurities. The build
system refers to absolute paths for tools like `ln` or `true`, which
was the real culprit here. Furthermore the build also 'helpfully'
suppresses errors in these cases by piping to /dev/null, so you never
see any errors at build time until it's too late (otherwise, you'd
see failures to call /bin/ln or at ./configure time).
This also re-enables parallel builds, as they should be safe from
all my testing, I believe.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Remove the parallel build[1], and update to the latest commit which
updates the .boot files and fixes a few bugs, too.
[1] I figured many builds on my dual-socket 12core would expose
problems, but I have a suspicion of that being an issue.
Signed-off-by: Austin Seipp <aseipp@pobox.com>