Building a C++ app using libxul

[Callum Prentice]

Has anyone successfully linked a Win32 C++ application against a recent
xulrunner build and libxul?

I'm working in the 1.8 Branch (so the winembed example in HEAD isn't
useful) and everything I've done to make XRE_InitEmbedding work causes
my application to crash.

--Callum

[bsme...@gmail.com]

Why isn't the winembed example useful? Admittedly it won't port
directly to branch, but you should still be able to read the code and
see how it bootstraps XPCOM/gecko.

[Callum Prentice]

I've been trying to do that for the last couple of days without a great
deal of success. Calls that presumeably work in winembed in HEAD fail
for me - GRE_GetGREPathWithProperties for instance. I had to #define
XPCOM_GLUE so that my call to XPCOMGlueStartup compiled and that
created lots of other compilation/linker errors - feels like I'm
chasing my tail.

[bsme...@gmail.com]

Have you read the XPCOM glue docs [1]? XPCOMGlueStartup only makes
sense if you're linking against xpcomglue.lib and defining XPCOM_GLUE.

You really need to decide which linking strategy you need up-front: if
you don't know where XULRunner will be installed (i.e. you're using a
system/shared XULRunner install), you need to use the standalone glue
(xpcomglue.lib, define XPCOM_GLUE). If you don't mind linking directly
against XPCOM/XUL, you should be using xpcomglue_s.lib and also linking
against xpcom.lib and xul.lib

[1] http://developer.mozilla.org/en/docs/XPCOM_Glue

[Callum Prentice]

Understood, I read those docs and tried to follow the advice but I
wasn't able to get a build. What I have now builds and runs properly
but I've a feeling my build environment is poorly configured (although
any changes I make to it causes things to stop building).

I'm aiming for a build where I point to my own XULRunner installation -
I.E. I'll supply whats in dist/bin/*.* myself from my build and have
XRE_InitEmbedding point to it.

My code needs to access internal Gecko functions and data types - e.g.
nsPresContext - I'd rather not but don't know how to do what I want
without doing so.

I define these in the preprocessor:
XP_WIN
XP_WIN32
MOZILLA_INTERNAL_API
XPCOM_GLUE

I link against these libraries that come from a recent Branch 1.8
xulrunner checkout/build:
nspr4.lib
plc4.lib
profdirserviceprovidersa_s.lib
xpcomglue.lib
xpcom_core.lib
xul.lib

I'd very much like to do things the proper way - any change to what I
have breaks things so I'm not sure what to do. I'm also aware that what
I'm doing is (hugely) unsupported and

Callum.

[bsme...@gmail.com]

Please, let's take this to the new newsgroup (mozilla.dev.builds)

It makes absolutely no sense to define MOZILLA_INTERNAL_API and
XPCOM_GLUE at the same time. It also makes no sense to define
XPCOM_GLUE while you're linking against xpcom.lib/xul.lib

Also, there should never be a xpcom_core.lib and a xul.lib at the same
time, unless you configured with --disable-libxul, which I strongly
discourage.

Try this set of defines:

XP_WIN
XP_WIN32
MOZILLA_INTERNAL_API

and linkage:

nspr4.lib
plc4.lib
xpcom.lib
xul.lib

What you are doing is *not* highly-unsupported. Obviously hacking the
gecko internals is not supported, but linking a C++ program and calling
XRE_InitEmbedding is a perfectly normal activity, even if there aren't
many examples yet.

--BDS