valgrind: Fix darwin build #29254
valgrind: Fix darwin build #29254
Conversation
LnL7
added
6.topic: darwin
|
I'm still seeing an issue with the build |
|
Hm. Ok. I'm on 10.11.6 and I've got Xcode Command line tools installed. (It seems that sometimes this is a problem) I've heard that sandboxed builds would help me getting more reproducible builds. How can I configure my nix, so I'll get the same build errors? |
|
Is this bzero-patch not needed anymore? |
|
As far as I can tell the patch was merged in: https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=f6d7adf7e983dea468c8cf337630acce902934e3 |
|
@LnL7: I suppose the reason for the build error is the following:
What would you suggest? |
|
Ok. I've tried to wrap my head around the |
The bzero-patch was merged upstream in git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16103, so it does no longer apply. Additionally - to make the build succeed on darwin systems more recent than our nixpkgs.darwin.xnu kernel version - we need to teach the build the version of the xnu headers we provide, instead of letting the build figure out the actual system version using `uname -r`.
knedlsepp
force-pushed
the
fix-valgrind
branch
from
05a133e
to
c71fd76
Compare
|
@LnL7: Since I've learned that upgrading the |
| preConfigure = stdenv.lib.optionalString stdenv.isDarwin ( | ||
| let OSRELEASE = '' | ||
| $(awk -F '"' '/#define OSRELEASE/{ print $2 }' \ | ||
| <${xnu}/Library/Frameworks/Kernel.framework/Headers/libkern/version.h)''; |
There was a problem hiding this comment.
we should add something for this to the xnu drv
There was a problem hiding this comment.
I've been thinking about that, since we actually already encode the macOS version. Sadly those don't easily transpose to the kernel version. Additionally there's only valgrind, IOKit, libpthread and network_cmds that depend directly on xnu(as far as I can tell.), so it might not be worth the effort.
There was a problem hiding this comment.
Yeah, first I was thinking about an attribute on xnu, but that could easily get out of sync. Adding a it to nix-support is the nicest alternative I could come up with, but that would be a mass-rebuild.
There was a problem hiding this comment.
This also seems like a fine solution.
Just to get an even broader view on the issue I'd like to mention that there also was an idea to replace uname itself: #25240
|
@knedlsepp Indeed, using the same versions of the sources is important for reproducibility and compatibility. We still support 10.10, even tho all of the hydra.org macs are running a more recent version. That's why we define Getting rid of the impurity that looks at the kernel version of the build host is definitely the preferred solution. But we could bump the version of xnu if that doesn't break things for older versions of OSX. |
LnL7
added
the
8.has: port to stable
|
Thank you for your work! Does this work on Sierra? On my system I get (say running I'm running 10.12.6 with no CLT or XCode. I've also tried building valgrind from current master (b9df4c8dec4d) instead of version 3.13.0. That didn't help. |
|
Hm. While this is unfortunate, I suppose it's quite likely that my patch wasn't that helpful after all. Valgrind probably has good reasons to do things differently for 10.12. I guess instead I should have tried bumping the xnu version as this is something I could actually test on my 10.11 system |
|
I've tried bumping xnu and got stuck with build error in coreutils (built as a stdenv dependency): To fix that I've tried to bump Libsystem and Libc, but that didn't help. Other possibility would be to supply bumped xnu only for valgrind. Not sure if that can work. |
veprbl
removed
the
9.needs: port to stable
Motivation for this change
Fix the darwin build of valgrind and valgrind-light as part of #29221
Things done
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)