Version: 3.7.0 OS: OS X The Makefiles contain hard coded paths ``` am__append_7 = \ /usr/include/mach/mach_vm.defs \ /usr/include/mach/task.defs \ /usr/include/mach/thread_act.defs \ /usr/include/mach/vm_map.defs ``` which then leads to ``` Making all in coregrind make[2]: *** No rule to make target `/usr/include/mach/mach_vm.defs', needed by `m_mach/mach_vmUser.c'. Stop. make[1]: *** [all-recursive] Error 1 ``` Further, the hard-coded /usr/include/mach/<something>.defs: ``` Making all in coregrind (cd m_mach && mig /usr/include/mach/mach_vm.defs /usr/include/mach/task.defs /usr/include/mach/thread_act.defs /usr/include/mach/vm_map.defs) (cd m_mach && mig /usr/include/mach/mach_vm.defs /usr/include/mach/task.defs /usr/include/mach/thread_act.defs /usr/include/mach/vm_map.defs) Error: No developer directory found at /Developer. Run /usr/bin/xcode-select to update the developer directory path. Error: No developer directory found at /Developer. Run /usr/bin/xcode-select to update the developer directory path. /usr/bin/mig: line 174: : command not found /usr/bin/mig: line 174: : command not found mig: fatal: "<no name yet>", line -1: mig: fatal: "<no name yet>", line -1: no SubSystem declaration no SubSystem declaration make[2]: *** [m_mach/taskUser.c] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [m_mach/mach_vmUser.c] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ``` First use xcrun to locate mig. Second, perhaps better use $SDKROOT/usr/include. If SDKROOT is not set, it defaults to /usr/include. New Xcode 4.3 does not install the headers there. Even the Command Line Tools for Xcode do not do this any longer. Reproducible: Always Steps to Reproduce: A Mac with Xcode 4.3 (and removed old remains of Xcode 4.2 via the uninstall-dev-tools before upgrading to 4.3) A freshly installed OS X 10.7.3 does not have these. Expected Results: make make install You can use Homebrew in order to brew install valgrind and see the problems discussed above.
Related discussion over at homebrew: https://github.com/mxcl/homebrew/issues/13042#issuecomment-6825680
I have a patch in my fork of homebrew: https://github.com/samueljohn/homebrew/commits/valgrind It works for me but probably a valgrind dev will want to have a look and incorporate the changes "the proper way".
Created attachment 72426 [details] git diff It's a git diff as we use them in homebrew.
I don't think this is a valid fix, as you're patching the automake generated Makefile (not the original from SVN). Regardless, the underlying issue is not present on current OS X (10.9) and Xcode 6 with its standard development environment.
(In reply to Rhys Kidd from comment #4) > I don't think this is a valid fix, as you're patching the automake generated > Makefile (not the original from SVN). > > Regardless, the underlying issue is not present on current OS X (10.9) and > Xcode 6 with its standard development environment. I'm seeing this exact issue in OS X Sierra (10.12.1), with valgrind from SVN (valgrind-3.13.0.SVN-16159-vex-3285) and Xcode 8.1. /usr/include does not exist on the machine. It's strange to me as a linux guy, but that's how it is. The actual headers are under: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ I'm able to compile software with homebrew. I'm also able to compile wine from git (not using homebrew), which also uses autoconf, so it's certainly possible to build software on OS X without /usr/include existing (wine also uses headers from mach/, but not the same ones as valgrind). I'll take a look at rebasing / fixing Samuel's patch.
Austin, Before you do, can you please confirm that you have the latest Xcode Command Line Tools installed? It is incremental on top of the basic Xcode package installed. Can be installed via: $ xcode-select --install
(In reply to Rhys Kidd from comment #6) > Austin, > > Before you do, can you please confirm that you have the latest Xcode Command > Line Tools installed? It is incremental on top of the basic Xcode package > installed. > > Can be installed via: > > $ xcode-select --install Yes, they are, otherwise I wouldn't be able to compile wine from the command line / use git ;)
To be more explicit: Austins-Mac-mini:~ austin$ xcode-select --install xcode-select: note: install requested for command line developer tools Austins-Mac-mini:~ austin$ ls /usr/ X11 adic bin lib libexec local sbin share standalone /usr/include is _not_ there by default, at least on Sierra, and likely other versions.
I'm almost certain there's a problem with your local copy of Xcode or with multiple versions of Xcode tripping up. It's well documented that /usr/include is not present by default on recent macOS, but is created via: $ xcode-select --install See further, as examples: [0] https://superuser.com/questions/995360/missing-usr-include-in-os-x-el-capitan [1] https://discussions.apple.com/thread/7124628?start=0&tstart=0
(In reply to Rhys Kidd from comment #9) > I'm almost certain there's a problem with your local copy of Xcode or with > multiple versions of Xcode tripping up. > > It's well documented that /usr/include is not present by default on recent > macOS, but is created via: > > $ xcode-select --install > > See further, as examples: > [0] > https://superuser.com/questions/995360/missing-usr-include-in-os-x-el-capitan > [1] https://discussions.apple.com/thread/7124628?start=0&tstart=0 Which is my point. If it's not present by default, it shouldn't be used. It's not included by default because there can be multiple versions of the SDK installed. Using the tip from https://stackoverflow.com/questions/6715454/what-is-the-default-path-for-osx-system-include-files-when-building-a-c-applic: $ echo "" | gcc -xc - -v -E On linux: ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include-fixed /usr/include End of search list. on mac: #include "..." search starts here: #include <...> search starts here: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.0.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks (framework directory) End of search list. and indeed, I have a copy of mach_vm.defs in: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach I have run xcode-select --install in the past (which is why I have git and other tools available, which work without /usr/include). I suspect the link was severed during an OS or SDK upgrade, but that's only speculating. If I re-run xcode-select --install, /usr/include exists and valgrind does compile. I still think it's a hack though, as this likely will break if someone tries to compile against a non-default SDK. Not to mention that it will presumably break in a future update, again.