Closed
Bug 1029974
Opened 10 years ago
Closed 3 years ago
Move framework args from TK_LIBS to moz.build
Categories
(Firefox Build System :: General, defect)
Tracking
(firefox97 fixed)
RESOLVED
FIXED
97 Branch
Tracking | Status | |
---|---|---|
firefox97 | --- | fixed |
People
(Reporter: rillian, Assigned: glandium)
References
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/x-phabricator-request
|
Details |
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.
Reporter | ||
Comment 1•10 years ago
|
||
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.
Reporter | ||
Comment 2•10 years ago
|
||
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
Assignee | ||
Comment 3•10 years ago
|
||
(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.
Reporter | ||
Comment 4•10 years ago
|
||
What can I do to support it?
Updated•7 years ago
|
Product: Core → Firefox Build System
Assignee | ||
Comment 5•3 years ago
|
||
Updated•3 years ago
|
Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/35f8b478f75b
Move frameworks from TK_LIBS to moz.build. r=firefox-build-system-reviewers,mhentges
Comment 7•3 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox97:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•