Bug 295084 - Hard-coded /usr/include
Summary: Hard-coded /usr/include
Status: RESOLVED NOT A BUG
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.7.0
Platform: Compiled Sources macOS
: NOR major
Target Milestone: ---
Assignee: Rhys Kidd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-29 18:37 UTC by Samuel John
Modified: 2017-02-07 23:40 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
git diff (2.28 KB, patch)
2012-07-10 10:52 UTC, Samuel John
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel John 2012-02-29 18:37:27 UTC
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.
Comment 1 Samuel John 2012-07-10 07:38:12 UTC
Related discussion over at homebrew: https://github.com/mxcl/homebrew/issues/13042#issuecomment-6825680
Comment 2 Samuel John 2012-07-10 10:51:07 UTC
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".
Comment 3 Samuel John 2012-07-10 10:52:36 UTC
Created attachment 72426 [details]
git diff

It's a git diff as we use them in homebrew.
Comment 4 Rhys Kidd 2014-10-09 10:46:03 UTC
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.
Comment 5 Austin English 2016-11-28 23:00:42 UTC
(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.
Comment 6 Rhys Kidd 2016-11-29 01:00:43 UTC
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
Comment 7 Austin English 2016-11-29 01:12:26 UTC
(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 ;)
Comment 8 Austin English 2016-11-29 01:13:23 UTC
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.
Comment 9 Rhys Kidd 2016-12-04 04:19:32 UTC
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
Comment 10 Austin English 2017-02-07 23:40:04 UTC
(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.