DYLD_INSERT_LIBRARIES no longer works on El Capitan

[jacereda]

No description provided.

[jacereda]

For build systems, a possible workaround would be to copy required tools out of the system path.

[ndmitchell]

What are the "required tools"? If someone runs gcc, which that involve copying gcc out of the system path? Or just the fsatrace dlls? Or something else? Is creating a symlink to whatever the relevant piece is sufficient?

[jacereda]

If you're using gcc it won't be installed in a system path, so it should be fine.
If you use the clang in Xcode, copying the clang binary to any non-system location and running from there should suffice. Maybe this could be built into the tool (check if the binary is present in /tmp/fsatrace/, copy if it isn't present and run from there).

[ndmitchell]

Is a hard link sufficient instead of an actual copy?

[jacereda]

I think hard links aren't allowed in 10.11.

[ndmitchell]

Hmm, won't copying the binary still change the argv[0] value, and thus things that go hunting for adjacent binaries (which I know gcc does) will fail. That seems even more problematic.

[jacereda]

Well, gcc binaries won't be signed nor installed on system paths. But yes, the solution wouldn't be very solid.

[jacereda]

I've started working on a workaround for this problem in shake:

jacereda/shake@cf5e949

But looks like I'm misunderstanding how newCacheIO works. Looks like /bin/sh is copied several times when running the lint test. What am I doing wrong? Is there a better way to achieve this?

[ndmitchell]

It looks sensible to me, at first brush. I suggest you add: print e just inside the newCacheIO. You should never get called with the same value twice. If you do, newCacheIO is wrong. If you don't, hopefully it will give you a clue as to why you are getting two bin/sh things.

[jacereda]

With this:

fcache <- newCacheIO $ \e -> liftIO $ do
    print e
    ...

I get several "/bin/sh" messages printed.

[ndmitchell]

Can you add a print just before fcache - ensure we're only creating one fcache value.

[jacereda]

OK, looks like running the test suite enters Development.Shake.Core.run several times. Is there a better place for that cache than Global? In any case, I don't mind if the test suite is a bit slower than it could because it copies binaries more times than necessary... I guess a normal build won't reenter run, right?

[ndmitchell]

The test suite calls run many many times.

Maybe the cache should exist only/mostly on disk? Why not just do a doesFileExist on the file you'd like to be there, and treat its presence as a signal than you've already copied it across. No need to newCacheIO at all.

Looking quickly, perhaps something like /bin/sh should be copied to $TEMP/fsatrace-fakes/<hash>/sh, where <hash> is the hash of /bin/sh - so if there are two sh binaries they don't get confused.

[jacereda]

Hmm, that would imply hashing the binary, I'll just prepend $TEMP to the found path, so if you have /bin/foo and /usr/bin/foo they will get different paths.

[ndmitchell]

I just meant hashing the filepath, but yeah, prepending $TEMP is a much simpler solution :)

[jacereda]

I'll just close this. If the hack ends up being too problematic, maybe by then Apple provides some decent way to trace binaries. Other than that, FUSE might be an option.