Might this be http://www.openradar.me/25313838 ?

Seems likely. I would expect Apple to fix a bug of this magnitude.

Meanwhile, if you're on a corp network, you can get an older version of Xcode here: https://gmac.corp.google.com/xcode/

I filed this as rdar://25346292 with a reference to 25313838.

Yep, I can downgrade, I know. I'm working on writing up a design doc, so I'll do that soon.

Can you run that clang command with -v so that we can see how it’s invoking the linker?

clang version 3.9.0 (trunk 263324)
Target: x86_64-apple-darwin15.4.0
Thread model: posix
InstalledDir: /Volumes/src/chrome-git/src/out/Debug/../../third_party/llvm-build/Release+Asserts/bin
 "/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -o chrome_dll_dependency_shim -lcrt1.10.6.o -L. -framework Cocoa -framework Foundation -framework IOKit -framework Security -framework SystemConfiguration -framework Cocoa -framework Foundation -framework IOKit -framework Security -framework SystemConfiguration -search_paths_first -pie -rpath @loader_path/. -rpath @loader_path/../../.. obj/chrome/obj/chrome/chrome_dll_dependency_shim.gen/chrome_dll_dependency_shim.dummy_main.o Chromium Framework.framework/Versions/A/Chromium Framework -framework AppKit -framework CoreFoundation -lSystem
ld: file not found: @rpath/libchrome_main_dll.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/V/s/c/s/o/Debug (rv-send) [1]> 

Is there a good way to get the linker option to the linker?

Add -Wl,-v.

But I think that message is coming from clang, which already showed you the linker invocation. The thing that prints the error probably isn’t testing for -v before giving you that hint.

/V/s/c/s/o/Debug (rv-send)> 
../../third_party/llvm-build/Release+Asserts/bin/clang -v -framework Cocoa -framework Foundation -framework IOKit -framework Security -framework SystemConfiguration -framework Cocoa -framework Foundation -framework IOKit -framework Security -framework SystemConfiguration -Wl,-search_paths_first -Wl,-pie -mmacosx-version-min=10.6 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -arch x86_64 -L. -Wl,-rpath,@loader_path/. -Wl,-rpath,@loader_path/../../.. -stdlib=libc++ -o chrome_dll_dependency_shim obj/chrome/obj/chrome/chrome_dll_dependency_shim.gen/chrome_dll_dependency_shim.dummy_main.o 'Chromium Framework.framework/Versions/A/Chromium Framework'  -framework AppKit -framework CoreFoundation -Wl,-v


clang version 3.9.0 (trunk 263324)
Target: x86_64-apple-darwin15.4.0
Thread model: posix
InstalledDir: /Volumes/src/chrome-git/src/out/Debug/../../third_party/llvm-build/Release+Asserts/bin
 "/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -o chrome_dll_dependency_shim -lcrt1.10.6.o -L. -framework Cocoa -framework Foundation -framework IOKit -framework Security -framework SystemConfiguration -framework Cocoa -framework Foundation -framework IOKit -framework Security -framework SystemConfiguration -search_paths_first -pie -rpath @loader_path/. -rpath @loader_path/../../.. obj/chrome/obj/chrome/chrome_dll_dependency_shim.gen/chrome_dll_dependency_shim.dummy_main.o Chromium Framework.framework/Versions/A/Chromium Framework -framework AppKit -framework CoreFoundation -v -lSystem
@(#)PROGRAM:ld  PROJECT:ld64-264.3.101
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
Library search paths:
	.
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib
Framework search paths:
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/
ld: file not found: @rpath/libchrome_main_dll.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/V/s/c/s/o/Debug (rv-send) [1]> 

I can reproduce this problem (or a similar one) with the kinda-reduced testcase from http://www.openradar.me/25313838, but that uses -flat_namespace, which seems to be required to make Xcode 7.3 ld64 break in this way. I can’t reproduce it using that testcase without -flat_namespace. We shouldn’t be using -flat_namespace anywhere.

Does the fact that I am doing the component build matter?

Certainly, I don’t think we do any rpath nonsense anywhere else.

I’m still finding it weird that I can only reproduce with -flat_namespace, but we shouldn’t be using that. Does Chromium Framework have MH_TWOLEVEL set in its mach_header64::flags field? (otool -hv will tell.)

Also, I bet you can paper over this problem by doing “ln -s @rpath .” in your out/Debug.

ln -s . @rpath

/V/s/c/s/o/Debug (rv-send) [1]> 
otool -hv Chromium\ Framework.framework/Versions/A/Chromium\ Framework 
Chromium Framework.framework/Versions/A/Chromium Framework:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    26       1776   NOUNDEFS DYLDLINK TWOLEVEL
/V/s/c/s/o/Debug (rv-send)> 

And yes, that symlink lets everything build.

haha :(

Yeah, pretty weak.

Based on ld64-253.3 source (from Xcode 7.0), lacking MH_NO_REEXPORTED_DYLIBS will also force a read of depended-on modules. See processDependentLibraries in src/ld/parsers/macho_dylib_file.cpp.

Also try -Wl,-dylib_file,@rpath/libchrome_main_dll.dylib,libchrome_main_dll.dylib while linking Chromium Framework. That may work without having to create a bogus symbolic link.

ld64-253.3 doesn’t seem to have any logic to understand @rpath either. I don’t know why we’re only seeing this break in Xcode 7.3. Maybe there’s some other factor that was causing these depended-on modules to not be read in older versions of ld.

We found a different workaround in our test case (http://www.openradar.me/25313838). Adding a trailing slash to the library search path helps to avoid the bug. Since this workaround would likely require gyp/gn support, it may not be feasible, though.

If you define RC_TRACE_DYLIB_SEARCHING=YES in your env, ld will spit out a ton of traces, which might help to understand the issue in your case.

Thanks for the awful hack. I "upgraded" before seeing the PSA, and that lets me be productive until I have a chance to downgrade and rebuild.

Moving this to assigned.

Will be fixed once https://codereview.chromium.org/1981583002/ is through the cq. (already works fine in gn builds.)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6d62dc019610a79e682b647e9482d5418d8e5447

commit 6d62dc019610a79e682b647e9482d5418d8e5447
Author: thakis <thakis@chromium.org>
Date: Fri May 13 23:37:33 2016

Roll src/tools/gyp/ 4cf07e8d6..bce1c7793 (3 commits).

https://chromium.googlesource.com/external/gyp.git/+log/4cf07e8d6167..bce1c7793010

$ git log 4cf07e8d6..bce1c7793 --date=short --no-merges --format='%ad %ae %s'
2016-05-13 thakis ninja/mac: Add horrible workaround for horrible Xcode 7.3 ld bug.
2016-05-04 scottmg Enabling /ZW (CompileAsWinRT) option for msvs
2016-04-26 iwilkins Adds support for a new target spec: 'mac_xcuitest_bundle'. This allows us to create UI testing bundles.

BUG= 597459 
TBR=scottmg

Review-Url: https://codereview.chromium.org/1981583002
Cr-Commit-Position: refs/heads/master@{#393692}

[modify] https://crrev.com/6d62dc019610a79e682b647e9482d5418d8e5447/DEPS

This should now work without workarounds.