Closed Bug 13129 Opened 20 years ago Closed 20 years ago
.exe work on all platforms
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.
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 ?
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
cc'ing simon fraser at his request
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: 20 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". :^)
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.
That's weird, it works on my Mac. Chris, can you include a stack trace?
Clearing FIXED resolution due to reopen.
Status: NEW → RESOLVED
Closed: 20 years ago → 20 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?
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.