Closed Bug 13129 Opened 25 years ago Closed 25 years ago

make regxpcom.exe work on all platforms

Categories

(Core :: XPCOM, defect, P2)

Product:
Core
Component:
XPCOM
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

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.
Blocks: 12562
Status: NEW → ASSIGNED
Priority: P3 → P2
Summary: make regFactory.exe work on all platforms → [perf] make regFactory.exe work on all platforms
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.
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 ?
Blocks: 7251
Target Milestone: M11
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
**************************************************
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
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.
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.
Summary: [perf] make regFactory.exe work on all platforms → [perf] make regxpcom.exe work on all platforms
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.
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.
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?
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
%
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]
cc'ing simon fraser at his request
Assignee: dp → rjc
Status: ASSIGNED → NEW
Robert has this working on the mac. The problem was the app wasn't being given
enough memory to work with.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
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?
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".  :^)
Status: RESOLVED → REOPENED
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.
Assignee: rjc → cyeh
Status: REOPENED → NEW
That's weird, it works on my Mac. Chris, can you include a stack trace?
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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.
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?
Blocks: 14217
ok , packaging & automation issues are logged in a separate bug: 14217. Please
respond there.
No longer blocks: 7251
Component: XPCOM Registry → XPCOM
QA Contact: dp → xpcom
You need to log in before you can comment on or make changes to this bug.