Closed
Bug 13129
Opened 25 years ago
Closed 25 years ago
make regxpcom.exe work on all platforms
Categories
(Core :: XPCOM, defect, P2)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
M11
People
(Reporter: Chris.Yeh, Assigned: Chris.Yeh)
References
Details
(Whiteboard: [Perf])
We need regFactory to work consistantly on all platforms so that we can run it
to generate component.reg files to ship with the final product.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Summary: make regFactory.exe work on all platforms → [perf] make regFactory.exe work on all platforms
Comment 1•25 years ago
|
||
This will improve performance of first time launch.
RegFactory works great on Win32. Unfortunately it doesn't work on UNIX, and
there wasn't a Mac project file to build it on Mac. Lovely.
smfr was kind enough to create a Mac project and did a test build, but it hosed
his machine...badly. We'll need to fix up the code to be Mac friendly.
Leaf added some stuff to the build system to make a component be generated on
Win32. We need to whip around the other platforms into shape.
Comment 3•25 years ago
|
||
Somebody lied to me that there was a mac project for it. Thanks simon.
I tested it under unix and it worked. Can you explain why it doesn't work on
unix. Like what the breakage is.
Would moving it from xpcom/test to xpcom/registry help you release folks ?
Comment 4•25 years ago
|
||
Ok I see the problem on unix. This one symbol is undefined.
Ramiro can you help ?
**************************************************
nsNativeComponentLoader:
Load(/home/dp/build.debug/mozilla/dist/bin/components/libgfxps.so) FAILED with
error: libraptorgfx.so: undefined symbol: NS_NewTimer__FPP8nsITimer
**************************************************
Comment 5•25 years ago
|
||
Looks like components/libgfxps.so is linking with bin/libraptorgfx.so which uses
NS_NewTimer(). And libraptorgfx.so cannot link in libtimer_s.a because the app
bin/apprunner will link with it.
Is the above reasoning right. As a temporary fix, I can try compiling RegFactory
with libtimer_s.a
Comment 6•25 years ago
|
||
It is fixed on unix. Simon is working on the mac.
Simon, I would like to move this to xpcom/registry/ and rename it to regxpcom.
Hope you haven't enabled the mac project file. Talk to you monday about fixing
this for the mac.
Comment 7•25 years ago
|
||
xpcom/tools/registry/regxpcom.cpp exists now. It is build on unix. I have
windows makefile.win changes that I will checkin once I verify it on my windows
build. (Good citizen ugh!)
Monday I will get help from Simon or another mac person to get this working on
the mac.
So use regxpcom. RegFactory will be removed.
Updated•25 years ago
|
Summary: [perf] make regFactory.exe work on all platforms → [perf] make regxpcom.exe work on all platforms
Comment 8•25 years ago
|
||
Added and fixed windows and unix. regxpcom.exe is the new incarnation.
xpcom/tools/registry/regxpcom.cpp
dp, i think that the "app" and regFactory should not link with $(MOZ_TIMER_LIBS)
instead, each component that uses the timer should.
I can checkin fixes for that. You can either file a bug for me for that, or
reassign and resummarize this one.
Comment 10•25 years ago
|
||
Ramiro the problem is a component links to a library in bin/ that uses timer.
The example here is:
components/libgfxps.so -> bin/libraptorgfx.so -> libtimer_s.a
You suggestion wont work for me. What would work is putting a libtimer_s.so and
getting libraries in bin/ link with it. That way, applications wont be forced to
link with it. Components/ as usual SHOULD link with the static timer.
Assignee | ||
Comment 11•25 years ago
|
||
just tried using regxpcom on unix. it ran.
component.reg -> 713 bytes
run apprunner
component.reg -> 232957 bytes
I would think that the results should be the same size in each case. Am I just
misunderstanding how this is supposed to work?
Comment 12•25 years ago
|
||
Nope that aint expected. There was another dependency that got introduced after
my fix saturday that cause dlls to fail in loading with symbol not found errors.
Fixed that. In my tree here is what I got. Let me know if you encounter more
trouble.
% rm component.reg
rm component.reg
% ./regxpcom
./regxpcom
Warning: MOZILLA_FIVE_HOME not set.
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
...deleting XPCOM
nsNativeComponentLoader: autoregistering
/home/dp/build.debug/mozilla/dist/bin/components
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
Registered Ok
*** Register XPConnect
*** Register XPConnect test components
*** Register libjar
*** Registering Security
*** Registering GFX Postscript
*** Registering GTK timer
*** Registering UnixToolkitService
*** Registering html library
*** XPInstall is being registered
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
nsBrowserInstance registration successful
nsFindComponent registration successful
nsUnknownContentTypeHandler registration successful
nsStreamTransfer registration successful
Registering the PrefsWindow
nsRegistry: Opening std registry
/home/dp/build.debug/mozilla/dist/bin/component.reg
nsNativeComponentLoader: autoregistering succeeded
% ls -l component.reg
ls -l component.reg
-rw-r--r-- 1 dp wheel 232707 Sep 13 17:47 component.reg
%
Comment 13•25 years ago
|
||
I made regxpcom build on Mac:
mozilla/xpcom/tools/registry/macbuild/RegXPCOM.mcp
However, it crashes when running, because huge amounts of memory seem to be being
leaked. Also, I haven't linked it with all the libs we need to avoid component
loading errors yet.
Summary: [perf] make regxpcom.exe work on all platforms → make regxpcom.exe work on all platforms
Whiteboard: [Perf]
Assignee | ||
Comment 14•25 years ago
|
||
cc'ing simon fraser at his request
Updated•25 years ago
|
Assignee: dp → rjc
Status: ASSIGNED → NEW
Comment 15•25 years ago
|
||
Robert has this working on the mac. The problem was the app wasn't being given
enough memory to work with.
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 16•25 years ago
|
||
I've fixed the RegXPCOM.mcp debug project on Mac by basically adding a SIZE
resource that gives the generated application a larger memory partition than the
largest component code fragment [I gave it 10 Megs of RAM, basically the same as
apprunner currently].
If the plan for the installer is to soft-link against a shared library version of
RegXPCOM, the same thing needs to be done for the installer [i.e. give it a SIZE
of 10 Megs or more] otherwise it'll suffer the same weirdness. The basic error
was that it couldn't load in layout's code fragment as it is currently over 4
Megs in size.
Comment 17•25 years ago
|
||
code fragments are not loaded into the heap when VM is on, so VM will have an
affect here. But I'm surprised that the heap must be that large.
BTW, why teh SIZE resource? Why not just set the project settings for partition
size?
Comment 18•25 years ago
|
||
Well, take whatever heap size is used by the application, and add to that the
size of the largest component you think you'll ever need to load in for
registration, and that should be the SIZE. We just picked 10 MB as it seems to
work for apprunner fairly well.
In regards to why we added a SIZE resource instead of just changing the project
settings, all I can say is "damn you, Simon". :^)
Assignee | ||
Comment 19•25 years ago
|
||
it's better, but it still crashes on Mac. It runs a lot longer than it used two,
and then dumps you into the debugger.
I'll try bumping up the memory some more or looking at it in macsbug to see if I
can figure out what is happening.
Updated•25 years ago
|
Assignee: rjc → cyeh
Status: REOPENED → NEW
Comment 20•25 years ago
|
||
That's weird, it works on my Mac. Chris, can you include a stack trace?
Comment 21•25 years ago
|
||
Clearing FIXED resolution due to reopen.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 22•25 years ago
|
||
huh. it works today. going to change the status to fixed.
JJ, please hook up RegXPCOM to the opimized build automation so we can deliver a
Component Registry as a part of the normal build.
Comment 23•25 years ago
|
||
I've updated BuildCentral to run RegXPCOM before packaging the Mac verification
build.
I noticed that this app is 1.1Mb large... should I delete it after execution to
reduce the package size?
Comment 24•25 years ago
|
||
ok , packaging & automation issues are logged in a separate bug: 14217. Please
respond there.
You need to log in
before you can comment on or make changes to this bug.
Description
•