Link static library with -force_load

[Catalin Badea]

Hello,

I'm trying to configure gyp to generate an xcode project which uses -force_load <lib> when linking against a static library listed as a dependency for the main target. I need to use force_load in order to work around a linker bug on mac 64-bit [1]. Using 'xcode_settings' and 'OTHER_LDFLAGS' is not particularly helpful because it is not usable for other build tools (e. g. ninja) and it requires hardcoding the library path.  

Does gyp support -force_load as a link option?

If not, is there another away to do this?

In case it might be relevant to the issue, building chromium on 64-bit mac requires chromium_main_dll to be linked against libbrowser_ui using -force_load.

Thank you,

Catalin Badea

[1] http://developer.apple.com/library/mac/#qa/qa1490/_index.html

[Mark Mentovai]

This sounds like a design problem or a bug, then. Why isn’t libbrowser_ui.a being loaded without -force_load? Why is this only a problem in your 64-bit configuration?

--
 
 
 

[Catalin Badea]

This is a linker bug that occurs when linking against Objective-C static libraries which contain categories.

From  http://developer.apple.com/library/mac/#qa/qa1490/_index.html :

"Important: For 64-bit and iPhone OS applications, there is a linker bug that prevents -ObjC from loading objects files from static libraries that contain only categories and no classes. The workaround is to use the -all_load or -force_load flags."

This is exactly the case with libbrowser_ui: using –force_load will fix "unrecognized selector" runtime errors.

Methods defined in browser_window_controller_private.mm are not linked into chrome_main_dll if –force_load is not used.

[Catalin Badea]

I haven't found any workaround for this issue.

I could work on adding support for the -force_load flag into gyp. Would that be a desirable feature for gyp?

[Mark Mentovai]

-force_load imposes a restriction that someone needs to declare, either when they’re depending on a library (bad) or in the target of the library itself (better, but still suboptimal) that -force_load is needed. I’d really prefer avoiding this type of .gyp target maintenance because it’s error-prone, especially as code is refactored and files move between targets. It also leaves open the very real possibility that old stale -force_loads will be left behind after they’re no longer needed, becoming yet another source of bloat. It’d be preferable if we could find some way to programmatically determine when -force_load or some other workaround needs to be applied, so that all of this maintenance could be handled in an automated (at .gyp or build time?) or semi-automated (presubmit check?) way. One possible semi-automated way we could do this AND sidestep -force_load would be to mandate “no categories allowed in a file unless it also implements a class.” That’s something that could be implemented in a presubmit check fairly easily. It seems like it would work based on the Apple doc you referenced, but I haven’t had time to test whether it would work in practice, to try other ideas related to this problem, or to verify that the bug is indeed still present in the most recent versions of Apple’s linker.

[Catalin Badea]

I have opened an issue on chromium about this[1], but, after testing on Mac OS X 10.7 and 10.8 I've discovered that the bug is no longer present in later versions of ld. Therefore, chromium would only require using a new version of ld.

[1] https://code.google.com/p/chromium/issues/detail?id=157577