Move framework args from TK_LIBS to moz.build

NEW
Unassigned

Status

defect
5 years ago
a year ago

People

(Reporter: rillian, Unassigned)

Tracking

Trunk
x86
macOS
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Bug 981428 moves a number '-framework Foo' link commands to the LDFLAGS stanzas in the local moz.build files for that particular feature.

The ones in toolkit/library/libxul.mozbuild end up on the final XUL link line, but the one in content/media/apple has no affect on the link, and that code only builds because the same framework argument is gives as part of the Cocoa TK_LIBS in configure.in.

Others, like dom/system/mac/moz.build don't add to LDFLAGS at all, also relying on TK_LIBS.
So two things:

libxul.mozbuild seems like a reasonable place for the frameworks actually required by the toolkit, so we should move those remaining in TK_LIBS there from configure.in.

For modules depending on particular frameworks we should fix merging their moz.build LDFLAGS into the final link and move any remaining frameworks to their modules.

As far as the second one goes, it looks like after bug 973649 we correctly generate MOZBUILD_LDFLAGS in the local backend.mk, but I haven't figured out why that isn't included in the ultimate link.
Depends on: 981428, 973649
As an example, this patch moving the CoreLocation reference to dom/system/mac/moz.build fails to link:

10:58.53 Undefined symbols for architecture x86_64:
10:58.53   "_OBJC_CLASS_$_CLLocationManager", referenced from:
10:58.53       objc-class-ref in CoreLocationLocationProvider.o
10:58.53   "_kCLLocationAccuracyBest", referenced from:
10:58.53       __GLOBAL__I_a in CoreLocationLocationProvider.o
10:58.53   "_kCLLocationAccuracyNearestTenMeters", referenced from:
10:58.53       __GLOBAL__I_a in CoreLocationLocationProvider.o
10:58.53 ld: symbol(s) not found for architecture x86_64
10:58.53 clang: error: linker command failed with exit code 1 (use -v to see invocation)
10:58.53 make[5]: *** [XUL] Error 1
(In reply to Ralph Giles (:rillian) from comment #1)
> For modules depending on particular frameworks we should fix merging their
> moz.build LDFLAGS into the final link and move any remaining frameworks to
> their modules.
> 
> As far as the second one goes, it looks like after bug 973649 we correctly
> generate MOZBUILD_LDFLAGS in the local backend.mk, but I haven't figured out
> why that isn't included in the ultimate link.

That's simply not supported.
What can I do to support it?

Updated

a year ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.