nsEmbedAPI.h declares NS_Embedding but no lib in xulrunner implements this function.
Or I'm at least unable to find it. The problem with this is that
Eclipse (SWT) needs this method to embed a gecko engine embedded.

This method should either be implemented or completely removed. I would
prefer to see the first but if its get removed what is the alternative
to use?


Cheers,
Michael

since your mail is @gmx.de i suspect it never ended in your mail box (I
often get bounces from there, but i'm getting so much fake or irrelevant
mailer daemon messages that i miss a lot of real ones :(

Here is what I wrote about the headers issue:

Looking at the source code for xulrunner, it's intentional. The problem
is headers are not necessarily in sync with the fact that symbols are
hidden...

And about the alternative:
You should patch the eclipse source to use NS_InitXPCOM3 or
NS_InitXPCOM2 instead, and that means you also have to add code for
components auto registration. Another option would be to look around if
a patch for eclipse exists to make it use javaxpcom instead of its own
xpcom stub. As of xulrunner 1.8.0.4-1, javaxpcom is not yet packaged,
but it is planned for 1.8.0.4-2.
If you opt for the first option and need help with embedding code, I
can give a hand. I'd personally prefer the second option.

Cheers,

Mike

since your mail is @gmx.de i suspect it never ended in your mail box (I
often get bounces from there, but i'm getting so much fake or irrelevant
mailer daemon messages that i miss a lot of real ones :(

Here is what I wrote about the headers issue:

Looking at the source code for xulrunner, it's intentional. The problem
is headers are not necessarily in sync with the fact that symbols are
hidden...

And about the alternative:
You should patch the eclipse source to use NS_InitXPCOM3 or
NS_InitXPCOM2 instead, and that means you also have to add code for
components auto registration. Another option would be to look around if
a patch for eclipse exists to make it use javaxpcom instead of its own
xpcom stub. As of xulrunner 1.8.0.4-1, javaxpcom is not yet packaged,
but it is planned for 1.8.0.4-2.
If you opt for the first option and need help with embedding code, I
can give a hand. I'd personally prefer the second option.

Cheers,

Mike

I have checked my mails again and I never got it. Damn GMX.

I think the symbol definition in the header should be removed then.

I think I opt for the first solution. It seems to be the less invasive
for me. Upstream still builds against Mozilla 1.4 and this is no chance
yet to make them support xulrunner.

Thanks for your help.


Michael

Damn RBLs :(

It should, but since it's not the only symbol for which it may be the
case, I prefer to do nothing before actually taking the time to check
everything.

I'd really go with the second option, especially considering [1]. At
least, I'd give the proposed patch a try.

Mike

1. https://bugs.eclipse.org/bugs/show_bug.cgi?id=79213