Bear is broken on 10.11 (.5) because of Library Validation

[jlargentaye (John de Largentaye)]

When trying to run a build on OS X 10.11.5 (El Capitan), I get:

$ bear make
dyld: warning: could not load inserted library '/usr/local/lib/libear.dylib' into library validated process because no suitable image found.  Did find:
	/usr/local/lib/libear.dylib: mmap() error 1 at address=0x105CDA000, size=0x00003000 segment=__TEXT in Segment::map() mapping /usr/local/lib/libear.dylib

And the compile_commands.json file is empty.

Investigation led me to processRestricted() in dyld: ​https://opensource.apple.com/source/dyld/dyld-360.22/src/dyld.cpp

Various sources online point to System Integrity Protection (SIP), but disabling that didn't change anything. I haven't yet found a workaround

[ryandesign (Ryan Carsten Schmidt)]

MacPorts does not install files in /usr/local, and installing files there manually while using MacPorts is not supported. Does /usr/local/lib/libear.dylib or /usr/local/bin/bear exist? If so, remove it.

[neverpanic (Clemens Lang)]

Even though I do not get the message when I run bear make, I know quite well what the problem is; Apple's SIP changes no longer allow DYLD_INSERT_LIBRARIES to affect binaries with the SIP-bit enabled. Unfortunately Apple's approach to marking binaries with the bit was "stick it on everything in /usr/bin and /bin", which includes tools used by many build systems such as the Shell, make, ln, mkdir, mv, rm, rmdir, chmod, cp, touch, install, and also clang and clang++.

This wouldn't be a problem if Apple's fallback solution for starting a SIP-binary with DYLD_INSERT_LIBRARIES set was disabling the entitlements (as if you were running a copy of the binary), but it isn't, so there's no good way around that for now.

The way we've solved that in MacPorts for our own use of DYLD_INSERT_LIBRARIES is hooking execvp and posix_spawn and transparently creating a copy of all SIP binaries without the SIP-bit. Instead of the original binary, we then run the copy (which isn't affected by the loader restriction) but set up argv[] in such a way that the binary itself doesn't notice under normal conditions.

A similar approach (or different workaround) would have to be implemented for Bear upstream. Please report the problem there, if it hasn't been reported already.

[neverpanic (Clemens Lang)]

Oh, and disabling SIP should work, but I haven't tried that and will not on my system. For the case without SIP, please see Ryan's comment; it shouldn't attempt to use /usr/local/lib/libear.dylib.

[jlargentaye (John de Largentaye)]

Thanks. Sorry for the invalid path libear.dylib, I had been experimenting with bear from various sources, and must've mistakenly copied the wrong session. I got the same errors with all of them.

It turns out disabling SIP *does* work. While I still get the dyld warning, a valid compile_commands.json is actually produced.

[l2dy (Zero King)]

See ​https://github.com/rizsotto/Bear/issues/152. If you're using make, you could try bear gmake instead.