ninja&make/mac: Give loadable_modules type MH_BUNDLE.

ninja&make/mac: Give loadable_modules type MH_BUNDLE.

BUG=chromium:280718
R=mark@chromium.org, mmoss@chromium.org

Committed: https://code.google.com/p/gyp/source/detail?r=1716

[Nico, 2013-09-05 04:11:09]

Do you know if this is still a useful / important distinction these days?

(Brett is wondering if we need this in gn – but it looks like it's easy to set
flags there, so it's probably easier to support than we though since this just
needs s/-shared/-bundle/. But I'd still like to hear your take on this
question.)

[Nico, 2013-09-05 04:11:45]

(looks like some of the tests fail, please wait with reviewing for a bit…)

[Nico, 2013-09-05 04:36:21]

Ok, this seems to work now. ptal.

https://codereview.chromium.org/23789004/diff/15001/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/23789004/diff/15001/pylib/gyp/xcode_emulation...
pylib/gyp/xcode_emulation.py:612: if install_name and self.spec['type'] !=
'loadable_module':
Surprisingly, Xcode still sets LD_DYLIB_INSTALL_NAME for non-bundle loadable
modules even though it doesn't tell the linker about the install_name.

https://codereview.chromium.org/23789004/diff/15001/test/module/src/module.gyp
File test/module/src/module.gyp (left):

https://codereview.chromium.org/23789004/diff/15001/test/module/src/module.gy...
test/module/src/module.gyp:39: 'xcode_settings': {'OTHER_LDFLAGS':
['-dynamiclib'], 'MACH_O_TYPE': ''},
Not sure what this was for. mmoss added it in
https://codereview.chromium.org/256020 , it looks strange to me.

[Mark Mentovai, 2013-09-05 14:29:37]

LGTM

The two chief differences between MH_DYLIB and MH_BUNDLE these days:

1. An MH_BUNDLE can be thought of as being implicitly linked against whatever
winds up loading it at runtime. dyld will resolve undefined symbols in an
MH_BUNDLE by using symbols exported by its loader. When building an MH_BUNDLE,
you can use ld -bundle_loader to specify the expected loader. MH_DYLIBs don’t
get this treatment: dyld won’t resolve anything in a loaded dylib based on
symbols already present in-process. This feature tends to be useful for plug-ins
to call back into whatever loaded them.

2. You can’t link something (meaning using ld) against an MH_BUNDLE.

https://codereview.chromium.org/23789004/diff/15001/pylib/gyp/generator/ninja.py
File pylib/gyp/generator/ninja.py (right):

https://codereview.chromium.org/23789004/diff/15001/pylib/gyp/generator/ninja...
pylib/gyp/generator/ninja.py:1930: command=solink_base %
{'suffix':solink_suffix, 'type': '-shared'},
Missing space before solink_suffix?

[Michael Moss, 2013-09-05 15:00:16]

https://codereview.chromium.org/23789004/diff/15001/test/module/src/module.gyp
File test/module/src/module.gyp (left):

https://codereview.chromium.org/23789004/diff/15001/test/module/src/module.gy...
test/module/src/module.gyp:39: 'xcode_settings': {'OTHER_LDFLAGS':
['-dynamiclib'], 'MACH_O_TYPE': ''},
On 2013/09/05 04:36:21, Nico wrote:
> Not sure what this was for. mmoss added it in
> https://codereview.chromium.org/256020 , it looks strange to me.

I don't know much about xcode, so I probably either got those settings from
another dev or migrated it from some other config (maybe from the scons days?).
If nobody else knows why it's needed, and it works without it, then LGTM.

[Nico, 2013-09-05 15:26:28]

Thanks!

[Nico, 2013-09-05 15:38:23]

Committed patchset #3 manually as r1716 (presubmit successful).