Closed Bug 88038 Opened 19 years ago Closed 8 years ago

regxpcom will not register statically linked components

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: waterson, Assigned: cathleennscp)

References

Details

Attachments

(1 file)

Since regxpcom doesn't have any of the static components linked into _it_, it
can't actually register them! This will be a problem for distributions,
particularly on Linux (where people want to be able to install a prefabricated
component registry as root via rpm, e.g.).

One gross possibility would be to munge the build order s.t. regxpcom is built
_last_, and links with all the static components (ick!). Any other ideas?
Blocks: 46775
actually, I just did a static build with our changes in bug 85770, and it works. 

because in a brand new build, there isn't any component.reg file, we would 
always run autoreg in that case.  :-)
Right, but that won't (?) work for people that want to make RPMs. Anyway, cc'ing 
blizzard who might want to comment. If he's okay with it, then let's close the 
bug.
Please don't close this bug.  You shouldn't have to run Mozilla to get the
registry created, and that's what you're saying here.  Please think about
multiuser systems; we screw them hard enough as it is. =/

Linking regxpcom with all the static components -- and maybe even stripping
unreferenced code, so that you just get the registration-specific stuff -- is
probably the best path here.  An alternative is to create a component that knows
how to recreate all of the registry entries for the static components, and link
just _that_ into regxpcom.  Harder, but likely possible -- we'd "just" need to
put a custom nsIRegistry implementation in place that intercepted and logged the
registry calls during autoreg.  We could perhaps cheat and just pull the
component and category data out of the registry post-build (requires us to run
Mozilla as part of the build process, happy happy joy joy) and file bugs on
things that expect to store registration-state in other places.
Here's an implementation of "one gross possibility".  Distributors beware: we
wind up with a regxpcom that's as large as the mozilla bin itself.  

The patch also factors out all of the static linking magic into a separate .mk
so that it doesn't need to be dupe in every makefile that links a static
executable.
What's the problem with just adding a command-line option to Mozilla that causes
it to auto-register and then exit?
Finding someone with the time to add that option, I think.  On the security
front, I think it's a big disconcerning to have to run the huge mozilla app as
root to generate component.reg for a multi-user setup.  Distributors may or may
not want to take that risk.

On a related note, what happens if we generate component.reg using mozilla-bin
(or regxpcom) and then run TestGtkEmbed?  Is there any chance of TestGtkEmbed
thinking that it has more components available than are built into it since it
uses a reduced component list to link against?
r=bryner for the makefile factoring portion of the patch.
Looks like this should fix bug 126165 too. But I must say, making regxpcom be 
the size of mozilla-bin is EXTREMELY gross. Its bad enough that the GTK embed 
tests all just grew to gigantic proportions. But this is enough to make me 
switch back to using dynamic builds for OpenVMS!
My other evil thought was to dlopen-or-equivalent the mozilla-bin executable to
grab the static component loader's data structure and use it to drive registration.

Less evil, but more work, would be to generate a mozilla-bin.reg file containing
the static component metadata, which could then be read in by regxpcom before
kicking off all the normal autoreg procedures.
That wouldn't work on OpenVMS. You can only dynamically load (dlopen) a 
shareable image, and mozilla-bin is not a shareable image.
I would rather not use mozilla-bin if possible.  It does a lot more than just
build a components.reg.
Keywords: mozilla1.0+
Any change in the status of this bug now that the registry format has changed?

So, we were inadvertantly banging our heads against this issue on the static
build tinderboxes.  The tinderboxes all run regxpcom which was creating a bogus
compreg.dat file and then causing the subsequent builds to fail.  Timeless'
checkin for bug 167174 which puts a .autoreg file in $(DIST)/bin fixed the
tinderbox issue by causing mozilla-bin to re-register themeselves.

This has brought up some question on IRC as to the need for regxpcom (in a
static build or otherwise) as well as the usefulness of the static build from a
distribution standpoint.
I definitely use regxpcom as part of the rpm builds.  I need regxpcom in order
to generate the files during upgrade.  You can't just wait for someone to run
mozilla since regular users won't be able to write to the install directory.

I wonder if the inclusing of .autoreg to the package files is going to break the
rpm builds, which use those files.
Adding dveditz for regxpcom, cathleen for static distro.
Blocks: 187834
I think I need this for apps that use the componentlib build. At least in that
case, regxpcom wouldn't be huge, like in a static build. It'll just dynamically
link with the componentlib, same as the app. It would still have to be built
after the componentlib, though :-/
Component: XPCOM Registry → XPCOM
QA Contact: rayw → xpcom
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.