Closed
Bug 768325
Opened 12 years ago
Closed 12 years ago
Need to be able to access libxul functions from gkmedia on windows for webrtc
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 699646
People
(Reporter: jesup, Unassigned)
Details
Attachments
(3 files, 4 obsolete files)
8.35 KB,
text/plain
|
Details | |
1.86 KB,
patch
|
Details | Diff | Splinter Review | |
5.29 KB,
patch
|
Details | Diff | Splinter Review |
We need to be able to access XPCOM/network/etc functions in liubxul from gkmedia on Windows, which is not currently possible. Suggestions from glandium and ted (ehsan was in agreement after the fact): 1) Try linking gkmedia as a static library with libxul with full PGO (now that we're on 64-bit windows builders) and see what the max memory usage is (with webrtc and signaling enabled, which would mean (currently) alder/default) 2) Try linking gkmedia as a static non-PGO library with xul and measure memory use. (I.e. add -Gy- by defining NO_PROFILE_GUIDED_OPTIMIZE=1) 3) Try moving media/webrtc/signaling (and probably ekr's transport code) to xul, leaving the rest of webrtc in gkmedia as current, and add a ton of C++ symbols to symbols.def.in (or find some more automatic way to do so). This is a bit of a maintenance nightmare due to having to track API changes and likely to be fragile (and may involve quite a few hacks along the way). I'll attach an IRC log with a bunch of details First step is to measure the memory use for cases #1 and #2. My initial try build using glandium's simple patch died with a bunch of unknown symbols (could be symbols.def.in biting us; I didn't debug - try build was triggered late Wednesday night/thurs morning EDT IIRC)
Reporter | ||
Comment 1•12 years ago
|
||
Comment 2•12 years ago
|
||
Comment on attachment 636733 [details] [diff] [review] Merge gkmedia in with XUL on windows Review of attachment 636733 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/library/Makefile.in @@ +547,5 @@ > +ifdef MOZ_WEBRTC > +EXTRA_DSO_LDOPTS += \ > + -LIBPATH:"$(MOZ_DIRECTX_SDK_PATH)/lib/$(MOZ_DIRECTX_SDK_CPU_SUFFIX)" \ > + $(NULL) > +OS_LIBS += $(call EXPAND_LIBNAME,secur32 crypt32 iphlpapi strmiids dmoguids wmcodecdspuuid amstrmid msdmo wininet) You're missing this: ifdef MOZ_CUBEB OS_LIBS += $(call EXPAND_LIBNAME, winmm) endif Note that if this works, you'll want to remove the parts you commented out, and also all EXTRA_DSO_LDOPTS and OS_LIBS in layout/media/Makefile.in.
Comment 3•12 years ago
|
||
Actually, if we go this way, we can just get rid of layout/media/Makefile.in and move things back in toolkit/library/Makefile.in.
Reporter | ||
Comment 4•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=0b3cc46f7b5d re: MOZ_CUBEB - right. I was mostly trying to get it to work and get the rough PGO memory reading; this isn't a review-ready patch.
Comment 5•12 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #4) > https://tbpl.mozilla.org/?tree=Try&rev=0b3cc46f7b5d > > re: MOZ_CUBEB - right. I was mostly trying to get it to work and get the > rough PGO memory reading; this isn't a review-ready patch. I know, I'm just saying, because MOZ_CUBEB is enabled by default.
Reporter | ||
Comment 6•12 years ago
|
||
Reporter | ||
Comment 7•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=1bb694191ec7 Win x32: linker max vsize: 3830517760 check: 19965/0 Win x64: linker max vsize: 3811520512 check: 19980/0 This would give us somewhere less than 464,xxx,xxx bytes (442MB), depending on how much of the 4GB address space is actually usable.
Reporter | ||
Comment 8•12 years ago
|
||
Patch used in try (basically) -- against alder/default
Attachment #636733 -
Attachment is obsolete: true
Attachment #637160 -
Attachment is obsolete: true
Comment 9•12 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #7) > https://tbpl.mozilla.org/?tree=Try&rev=1bb694191ec7 > > Win x32: > linker max vsize: 3830517760 > check: 19965/0 > > Win x64: > linker max vsize: 3811520512 > check: 19980/0 > > This would give us somewhere less than 464,xxx,xxx bytes (442MB), depending > on how much of the 4GB address space is actually usable. How much is the linker max vsize with the same code, but with gkmedias separated?
Comment 10•12 years ago
|
||
That doesn't seem like it gives us a lot of breathing room, especially considering that we have no recourse when we hit the 4GB limit.
Comment 11•12 years ago
|
||
(In reply to Ted Mielczarek [:ted] from comment #10) > That doesn't seem like it gives us a lot of breathing room, especially > considering that we have no recourse when we hit the 4GB limit. Let's see how it goes with webrtc not PGOed.
Reporter | ||
Comment 12•12 years ago
|
||
For reference, a recent Win x32 PGO build on m-c: linker max vsize: 3166093312 check: 23285/0 Increase for including all of gkmedia and media/webrtc (which includes ~750K lines of code, plus an additional ~500K lines of code on alder that mostly will not land on m-c!) is ~670MB
Reporter | ||
Comment 13•12 years ago
|
||
Reporter | ||
Comment 14•12 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Attachment #637360 -
Attachment is obsolete: true
Reporter | ||
Comment 15•12 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Attachment #637657 -
Attachment is obsolete: true
Comment 16•12 years ago
|
||
Just going to fix this over in bug 699646.
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•