On Thu, Aug 17, 2006 at 12:18:21AM +0200, Marc Gueury <[EMAIL PROTECTED]> wrote:
> Hi Mike,
>
> I would like so much that what you say would be true. It would
> ease my life a lot. The problem is that I was not doing it before
> and I had to recompile the extension for each version of Firefox
> for each platform to let it work...
>
> The reason is that when you link with xpcom_glue. You link only with frozen
> interface that have to match in each version of the library. Between
> version other xpcom functions have changed of signature. So, it is not
> possible
> to link against XPCOM.
>
> If you are able to show me the opposite. I am opened to listen.
> But I have already tried and it does not unhappily work :-)
>
> Please read this:
>
> http://developer.mozilla.org/en/docs/XPCOM_Glue
As usual, they have a tendency to give bad solutions to problems they
could have avoided in the first place. Anyway...
On the page you quote, I read:
Embedding code which wishes to use only frozen symbols and cannot
tolerate a load-time dependency on xpcom.dll should #define XPCOM_GLUE
while compiling, and link against xpcomglue.lib. It should not link
against xpcomglue_s.lib or xpcom.lib.
So let me see...
In your source, I read in mozilla/extensions/tidy/src/Makefile.in:
DEFINES += -DXPCOM_GLUE
EXTRA_DSO_LDOPTS = \
$(DIST)/lib/$(LIB_PREFIX)xpcomglue.$(LIB_SUFFIX) \
(...)
Ok. That's what you do.
Further reading:
In order to use XPCOM, the embedding application first needs to find
where the XPCOM runtime is located. This is typically done using
GRE_GetGREPathWithProperties. Then, the code must call XPCOMGlueStartup,
which will dynamically link against the XPCOM runtime. Only then can the
embedding application initialize and use XPCOM.
I see no XPCOMGlueStartup in your code...
Let's continue to read:
This linkage strategy is used when an embedder needs to bootstrap an
embedding app by finding a compatible GRE. Extension or XULRunner
application components should use the dependent glue.
Ah ? Extensions should use the dependent glue, but what is it:
Code which wishes to use only frozen symbols but can tolerate a
load-time dependency on xpcom.dll should link against xpcom.lib and
xpcomglue_s.lib.
This is exactly what you should be doing, especially considering the
following sentence:
This is the case for XPCOM components.
Guess what, that's exactly what the nsTidyModule is: a XPCOM component.
Either way (dependent or standalone glue), you're not doing what you're
supposed to. Either you have to add initialization code for the
standalone glue, so that it loads the xpcom library, either you link
against the dependent glue. The fact that it works as is with official
builds is a corner case.
Anyways, since it seems that quite some extensions are built this way,
we'll have to put some workaround. I only need to decide what kind of
workaround exactly should be put. In the meanwhile, people can add
export LD_PRELOAD=/usr/lib/firefox/libxpcom.so
in their $HOME/.mozilla/firefox/rc or in /etc/firefox/firefoxrc
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
