88038 - regxpcom will not register statically linked components

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Chris Waterson]

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?

Comment 1

[Cathleen]

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.  :-)

Comment 2

[Chris Waterson]

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.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 4

[hacker formerly known as [e-mail]]

Attachment: "gross possibility"

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.

Comment 5

[Brian Ryner (not reading)]

What's the problem with just adding a command-line option to Mozilla that causes
it to auto-register and then exit?

Comment 6

[hacker formerly known as [e-mail]]

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?

Comment 7

[Brian Ryner (not reading)]

r=bryner for the makefile factoring portion of the patch.

Comment 8

[Colin Blake]

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!

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 10

[Colin Blake]

That wouldn't work on OpenVMS. You can only dynamically load (dlopen) a 
shareable image, and mozilla-bin is not a shareable image.

Comment 11

[Christopher Blizzard (:blizzard)]

I would rather not use mozilla-bin if possible.  It does a lot more than just
build a components.reg.

Comment 12

[hacker formerly known as [e-mail]]

Any change in the status of this bug now that the registry format has changed?

Comment 13

[hacker formerly known as [e-mail]]

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.

Comment 14

[Christopher Blizzard (:blizzard)]

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.

Comment 15

[Chris McAfee]

Adding dveditz for regxpcom, cathleen for static distro.

Comment 16

[Conrad Carlen (not reading bugmail)]

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 :-/