The Mac OS X framework has a wrong rpath.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create new Xcode project.
2. Add Chromium Embedded Framework.framework as an Embedded Binary, which will 
cause it to be copied to the bundle.
3. Fiddle with signing issues until it works, my recommendation, try disabling 
signing everywhere.
4. Compile and run and you'll get this error:

dyld: Library not loaded: @executable_path/Chromium Embedded Framework
  Referenced from: /Users/pupeno/Library/Developer/Xcode/DerivedData/cefobjc-bxtruyemnyagwwgdejtzuxngovsr/Build/Products/Debug/cefobjc.app/Contents/MacOS/cefobjc
  Reason: image not found

The reason is that the rpath of the framework is not correct, it's: 

@executable_path/Chromium Embedded Framework

when it should be:

@rpath/Chromium Embedded Framework.framework/Chromium Embedded Framework

so that the framework is easily reusable in other frameworks and apps. You can 
inspect this value with:

otool -D Chromium\ Embedded\ Framework.framework/Chromium\ Embedded\ Framework

and I fixed it with:

install_name_tool -id "@rpath/Chromium Embedded Framework.framework/Chromium 
Embedded Framework" Chromium\ Embedded\ Framework.framework/Chromium\ Embedded\ 
Framework

There's more information about this here: 
https://mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html

Original issue reported on code.google.com by pup...@pupeno.com on 26 Feb 2015 at 10:07

[GoogleCodeExporter]

> @rpath/Chromium Embedded Framework.framework/Chromium Embedded Framework

That would not be correct for all executables. For example, the Helper 
executables live at "<appname>.app/Contents/Frameworks/<appname> 
Helper.app/Contents/MacOS/<appname>" and so on. You should instead fix the 
framework link in the executable (main executable, helper executables, etc). 
See for example the FIX_MACOSX_*_FRAMEWORK_LINK CMake macros provided with the 
binary distribution:

https://code.google.com/p/chromiumembedded/source/browse/trunk/cef3/macros.cmake
.in#173

Original comment by magreenb...@gmail.com on 26 Feb 2015 at 10:49

• Changed state: WontFix

[GoogleCodeExporter]

If Chromium Embedded Framework.framework is in Content/Frameworks of the 
Helper.app, then, shouldn't that rpath work? Isn't that the whole point of 
rpath? 
https://mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html

Original comment by pup...@pupeno.com on 27 Feb 2015 at 1:34

[GoogleCodeExporter]

The framework is not inside the Helper app bundles. See the directory structure 
in the README.txt file included with the binary distribution.

Original comment by magreenb...@gmail.com on 27 Feb 2015 at 2:57

[GoogleCodeExporter]

I'm sorry to keep coming back to this, but I'm actually new to both cef and 
cocoa. I'm trying to build an xcode project that uses cef that requires as 
little extra steps as possible. After changing the rpath like I showed before, 
calling it from the main app require no extra steps as that rpath is designed 
to work well in that scenario.

I removed it from the helper app to avoid having two copies of the framework 
and I added this path to the runpath for the helper app:

@executable_path/../../../../Frameworks

so that it can find frameworks from the parent app and with that, it worked 
too. That wouldn't work, as far as I understand, without using rpath in the 
path of the Framework.

Original comment by pup...@pupeno.com on 2 Mar 2015 at 4:48

[GoogleCodeExporter]

I got this when I used makefiles.  using Ninja appears to avoid this and other 
problems.
The README doesn't quite say Makefiles are unsupported, but it does point you 
to CMakeLists.txt,
whose comments suggest using Ninja.

Original comment by daniel.r...@gmail.com on 30 Apr 2015 at 5:10