Mikhail Naganov wrote: > Also answering on Mark's question. > > $ pwd > /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS [...] > $ ./Chromium > <<< this way, it fails >>>
OK, I know what's happening here. Having a dot after MacOS in the path to the executable is what breaks things. I usually sit in the Release directory and start Chromium as: $ Chromium.app/Contents/MacOS/Chromium > Here is the value of 'path' when running from Terminal: > /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/./Chromium There's the dot I'm talking about. > When I run it under gdb, the path is printed two times: > /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/Chromium > /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/Versions/4.0.223.1/Chromium Helper.app/Contents/MacOS/Chromium Helper Right, once from the browser process (the one we care about) and once from the first renderer (which never gets a chance to start up when you have the dot in an unexpected spot). If you had tried a debug build, you would have seen output like this: [mmdd/hhmmss:FATAL:/chrome/trunk/src/base/mac_util.mm(80)] Check failed: bundle. failed to load the bundle: .../Debug/Chromium.app/Contents/MacOS/Versions/4.0.223.2/Chromium Framework.framework The framework should be at Chromium.app/Contents/Versions/4.0.223.2. The code that builds the path to the framework is not expecting a dot after MacOS in the pathname, it's just stripping a fixed number of components (2) off of the executable's pathname, expecting it to be .../Contents/MacOS/Chromium. You can use "don't put dots there" as a workaround in the mean time, and I'll cook up something to fix this in the code. Mark --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
