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

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?

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.

From: Mark Mentovai <m...@chromium.org<mailto:m...@chromium.org>>
Date: Tue, 2 Oct 2012 14:15:52 +0100
To: Catalin Badea <ba...@adobe.com<mailto:ba...@adobe.com>>
Cc: gyp-developer <gyp-developer@googlegroups.com<mailto:gyp-developer@googlegroups.com>>
Subject: Re: [gyp-developer] Link static library with -force_load

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?

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

--

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?

-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.

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

luni, 8 octombrie 2012, 18:34:00 UTC+3, Mark Mentovai a scris: