Summary: | Hard-coded /usr/include | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Samuel John <kde> |
Component: | general | Assignee: | Rhys Kidd <rhyskidd> |
Status: | RESOLVED NOT A BUG | ||
Severity: | major | CC: | austinenglish, rhyskidd |
Priority: | NOR | ||
Version: | 3.7.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | git diff |
Description
Samuel John
2012-02-29 18:37:27 UTC
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. |