@larkost What lead you to conclude that DYLD_LIBRARY_PATH was no longer supported?

There have been a few comments in the Apple developer forums about people having similar problems on El Capitan dev/beta builds and coming to this conclusion. And Apple is focusing on "runtime" security protections so it is a good guess about what is going on. But the main evidence is that this is failing with the only change being me moving to El Capitan public beta. We won't get anything official out of Apple until it comes out, far too late in my opinion.

So unless you believe that either we should not support building on El Capitan, or that it will start working again with no involvement from us, we are going to have to work around this.

I think that this URL is open to the public (but have enough cookies from Apple on my system that I could be wrong): https://forums.developer.apple.com/message/31148

If the speculation is correct, then we indeed can't use the DYLD_LIBRARY_PATH route. And I already checked, the DYLD_FALLBACK_LIBRARY_PATH route is also blocked in the latest Public Beta.

That link worked for me, thanks for sharing. Does the dyld man page on 10.11 say anything about that change?

An alternative solution would be to replace the use of DYLD_LIBRARY_PATH by setting an rpath in the LDFLAGS.

The rpath method does not look like it is a viable one, at least not with out understanding the two nested build systems that v8 uses than I managed to get. The naive solution of just adding path to the LDFLAGS fails because the gyp build layer tries to use use the LD_FLAGS during compilation as well, so clang complains that that is not a valid build flag.

I was also stymied in an attempt to only add the rpath to just the part that builds the mksnapshot binary that v8 uses to make the pre-assemembed version of icu that it uses internally, since that is the only part of this that is actually problematic. The main problem is that I can't find any documentation on how the gn toolset (google's replacement for their own gyp system, that they are moving to on a rolling basis) is not well documented, and I have been unable to tap my way though to getting it to either use a rpath or build statically.

But topping all of this off is that I don't think that any of this route would actually save us any real space or time. Even when using the "system" version of icu the v8 build system is still pre-compiling all of this. So we do save on the initial compile, but a copy of this still winds up linked statically into our binary.

Given that we are not saving much, my proposal is to cut the corner and just let v8 build its own icu, and like to that one. I already have a version of this done and it is working. I will clean this up and submit it shortly. Other than #4895 this allows us to build successfully on MacOS X ElCapitan (10.11).

It has been decided that we are going to do this and only use the embedded version if icu. Additionally rather than importing all of the version of icu that v8 uses (~5300 files), and we deleted before importing all of v8, we are going to remove v8 from our git repository[1] and let the download system take over that. There was some commentary about this in #1231 and #1743, but we think it is the lesser evil.

The other note to make on this is that we will no longer explicitly list and of the icu libraries in our makefiles. Rather they will be implicitly brought in by the v8 module. This is imperfect, but all of the other options that we thought of had nasty flaws in them, or felt hask-ish.

[1] The files will still be in our git history, but not at HEAD

This is up for review in CR 3262 from branch larkost/4602-ElCapitan-build-fix. The solution removes all of v8 that we currently have in our source, letting it get download as needed. Additionally it removes that ability to use the system-installed version of icu, rather deferring to the version that comes with v8.

This has been merged into next with 276b266, and v2.1.x with 8b6c481.