Firefox build changing to --enable-libxul

NAVIGATION

CATEGORIES

Mozilla

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Mozilla

Firefox build changing to --enable-libxul
10 answers - 998 bytes -
The Firefox trunk build will be changing to use by default
sometime early next week. This should not (knock on wood) have any
user-visible effects, but it will have some consequences for development:
1) xpcom_core.{dll,so,dylib} will no longer exist, it will be rolled into
the larger xul.dll/libxul.so/XUL library.
2) the "internal linkage" functions are not exported from libxul, so it will
no longer be possible to compile extension code using internal linkage (if
you don't know what this means, see the linkage descriptions at
).
3) developers who are hacking the core code will want to add
to their mozconfig: this breaks "libxul" out into all the
shared libraries that you know and love, including xpcom_core, gklayout,
etc. You can add the flag to your development-tree
mozconfig now, you don't have to wait until next week's landing.
dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.1 | | 7230 bytes | |
Hello Benjamin,

Friday, August 4, 2006, 6:07:16 PM, you wrote:

BS2) the "internal linkage" functions are not exported from libxul, so it will
BSno longer be possible to compile extension code using internal linkage
xpctools can not be build on Win32 after latest code update.
I've used `' for long time without problems, and today got these errors:

make[6]: Entering directory `/'
/ link -NLG -DLL UT:xpctools.dll -PDB:xpctools.pdb -SUBSYSTEM:WINDWS nsXPCToolsCompiler.obj nsXPCToolsProfiler.obj nsXPCToolsModule.obj ./module.res -IMPLIB:fake.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib
Creating library fake.lib and object fake.exp
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: __thiscall nsCMPtr_base::~nsCMPtr_base(void)" (?1nsCMPtr_base@@QAE@XZ) referenced in function "public: __thiscall nsCMPtr<class nsISupports>::~nsCMPtr<class nsISupports>(void)" (?1?$nsCMPtr@VnsISupports@@@@QAE@XZ)
nsXPCToolsProfiler.obj : error LNK2001: unresolved external symbol "public: __thiscall nsCMPtr_base::~nsCMPtr_base(void)" (?1nsCMPtr_base@@QAE@XZ)
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: static void const * const ACString::sCanonicalVTable" (?sCanonicalVTable@ACString@@2PBXB) referenced in function "protected: __thiscall (char *,unsigned int,unsigned int)" (?0nsACString_internal@@IAE@PADII@Z)
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: __thiscall nsACString_internal::~nsACString_internal(void)" (?1nsACString_internal@@QAE@XZ) referenced in function "public: __thiscall nsCSubstring::~nsCSubstring(void)" (?1nsCSubstring@@QAE@XZ)
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: void __fastcall (class const &,struct nsID const &)" (?@nsCMPtr_base@@@@ABUnsID@@@Z) referenced in function "public: __thiscall nsCMPtr<class nsIProperties>::nsCMPtr<class nsIProperties>(class const &)" (?0?$nsCMPtr@VnsIProperties@@@@QAE@@@@Z)
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: void __fastcall nsCMPtr_base::assign_from_qi(class nsQueryInterface,struct nsID const &)" (?assign_from_qi@nsCMPtr_base@@QAIXVnsQueryInterfa ce@@ABUnsID@@@Z) referenced in function "public: __thiscall nsCMPtr<class nsILocalFile>::nsCMPtr<class nsILocalFile>(class nsQueryInterface)" (?0?$nsCMPtr@VnsILocalFile@@@@QAE@VnsQueryInterfa ce@@@Z)
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: void __fastcall (class nsGetServiceByCIDWithError const &,struct nsID const &)" (?assign_from_gs_cid_with_error@nsCMPtr_base@@@@AB UnsID@@@Z) referenced in function "public: __thiscall nsCMPtr<class nsIXPConnect>::nsCMPtr<class nsIXPConnect>(class nsGetServiceByCIDWithError const &)" (?0?$nsCMPtr@VnsIXPConnect@@@@QAE@ABVnsGetService ByCIDWithError@@@Z)
nsXPCToolsProfiler.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall nsHashKey::Write(class nsIStream *)const " (?Write@nsHashKey@@UBEIPAVnsIStream@@@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall nsHashKey::~nsHashKey(void)" (?1nsHashKey@@UAE@XZ) referenced in function "public: virtual void * __thiscall nsHashKey::`scalar deleting destructor'(unsigned int)" (?_GnsHashKey@@UAEPAXI@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: __thiscall nsHashtable::nsHashtable(unsigned int,int)" (?0nsHashtable@@QAE@IH@Z) referenced in function "public: __thiscall ProfilerFile::ProfilerFile(char const *)" (?0ProfilerFile@@QAE@PBD@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: void __thiscall nsHashtable::Enumerate(int (__cdecl*)(class nsHashKey *,void *,void *),void *)" (?Enumerate@nsHashtable@@QAEXP6AHPAVnsHashKey@@PAX 1@Z1@Z) referenced in function "public: void __thiscall (int (__cdecl*)(class nsHashKey *,void *,void *),void *)" (?EnumerateFunctions@ProfilerFile@@QAEXP6AHPAVnsHa shKey@@PAX1@Z1@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: void * __thiscall nsHashtable::Remove(class nsHashKey *)" (?Remove@nsHashtable@@QAEPAXPAVnsHashKey@@@Z) referenced in function "void __cdecl xpctools_JSDestroyScriptHook(struct JSContext *,struct JSScript *,void *)" (?xpctools_JSDestroyScriptHook@@YAXPAUJSContext@@P AUJSScript@@PAX@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: void * __thiscall nsHashtable::Get(class nsHashKey *)" (?Get@nsHashtable@@QAEPAXPAVnsHashKey@@@Z) referenced in function "void * __cdecl xpctools_InterpreterHook(struct JSContext *,struct JSStackFrame *,int,int *,void *)" (?xpctools_InterpreterHook@@YAPAXPAUJSContext@@PAU JSStackFrame@@HPAHPAX@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: void * __thiscall nsHashtable::Put(class nsHashKey *,void *)" (?Put@nsHashtable@@QAEPAXPAVnsHashKey@@PAX@Z) referenced in function "public: class ProfilerFunction * __thiscall ProfilerFile::FAddFunction(char const *,unsigned int,unsigned int,unsigned int)" (?FAddFunction@ProfilerFile@@QAEPAVProfilerFunctio n@@PBDIII@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall nsCStringKey::~nsCStringKey(void)" (?1nsCStringKey@@UAE@XZ) referenced in function "void __cdecl xpctools_JSNewScriptHook(struct JSContext *,char const *,unsigned int,struct JSScript *,struct JSFunction *,void *)" (?xpctools_JSNewScriptHook@@YAXPAUJSContext@@PBDIP AUJSScript@@PAUJSFunction@@PAX@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: __thiscall nsCStringKey::nsCStringKey(char const *,int,enum nsCStringKey::)" (?0nsCStringKey@@QAE@PBDHW@0@@Z) referenced in function "void __cdecl xpctools_JSNewScriptHook(struct JSContext *,char const *,unsigned int,struct JSScript *,struct JSFunction *,void *)" (?xpctools_JSNewScriptHook@@YAXPAUJSContext@@PBDIP AUJSScript@@PAUJSFunction@@PAX@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: void __fastcall (class nsGetServiceByContractID,struct nsID const &)" (?assign_from_gs_contractid@nsCMPtr_base@@QAIXVnsG etServiceByContractID@@ABUnsID@@@Z) referenced in function "public: __thiscall nsCMPtr<class nsIJSRuntimeService>::nsCMPtr<class nsIJSRuntimeService>(class nsGetServiceByContractID)" (?0?$nsCMPtr@VnsIJSRuntimeService@@@@QAE@VnsGetSe rviceByContractID@@@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: void __thiscall nsHashtable::Reset(int (__cdecl*)(class nsHashKey *,void *,void *),void *)" (?Reset@nsHashtable@@QAEXP6AHPAVnsHashKey@@PAX1@Z1 @Z) referenced in function "public: virtual __thiscall nsXPCToolsProfiler::~nsXPCToolsProfiler(void)" (?1nsXPCToolsProfiler@@UAE@XZ)
nsXPCToolsModule.obj : error LNK2019: unresolved external symbol "unsigned int __cdecl NS_NewGenericModule2(struct nsModuleInfo const *,class nsIModule * *)" (?NS_NewGenericModule2@@YAIPBUnsModuleInfo@@PAPAVn sIModule@@@Z) referenced in function _NSGetModule
xpctools.dll : fatal error LNK1120: 18 unresolved externals
No.2 | | 489 bytes | |
Lev Serebryakov wrote:

xpctools can not be build on Win32 after latest code update.
I've used `' for long time without problems, and today got these errors:

I have never built with I suggest you file a bug (and fix
it!). Basically you'll have to change the xpctools code to not use
MZILLA_INTERNAL_API.

The immediate cause of this change was this checkin:

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.3 | | 634 bytes | |
Benjamin Smedberg wrote:
3) developers who are hacking the core code will want to add
to their mozconfig: this breaks "libxul" out into all
the shared libraries that you know and love, including xpcom_core,
gklayout, etc. You can add the flag to your
development-tree mozconfig now, you don't have to wait until next week's
landing.

What's the impact if we don't make this change? Longer build times?
Confusion as to what top level directories need to be rebuilt after a
core change?
- Aaron

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.4 | | 1140 bytes | |
Aaron Leventhal wrote:
Benjamin Smedberg wrote:
>3) developers who are hacking the core code will want to add
>to their mozconfig: this breaks "libxul" out into all
>the shared libraries that you know and love, including xpcom_core,
>gklayout, etc. You can add the flag to your
>development-tree mozconfig now, you don't have to wait until next
>week's landing.

What's the impact if we don't make this change? Longer build times?
Confusion as to what top level directories need to be rebuilt after a
core change?

Because libxul is a large library encompassing pretty much everything in
tier 9 and tier 50 (all of gecko and toolkit), it can take a long time to
build, require lots of RAM to link, and making changes and rebuilding is
complicated by the fact that you have to rebuild toolkit/library every time
you make a change. If you're ok with that in your development trees, you're
welcome to keep the default setting.

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.5 | | 1238 bytes | |
Benjamin Smedberg wrote:
The Firefox trunk build will be changing to use by default
sometime early next week. This should not (knock on wood) have any
user-visible effects, but it will have some consequences for development:

1) xpcom_core.{dll,so,dylib} will no longer exist, it will be rolled into
the larger xul.dll/libxul.so/XUL library.

2) the "internal linkage" functions are not exported from libxul, so it will
no longer be possible to compile extension code using internal linkage (if
you don't know what this means, see the linkage descriptions at
).

3) developers who are hacking the core code will want to add
to their mozconfig: this breaks "libxul" out into all the
shared libraries that you know and love, including xpcom_core, gklayout,
etc. You can add the flag to your development-tree
mozconfig now, you don't have to wait until next week's landing.

Can you give an idea to us non-devs what (if any) changes this will
bring? Will it improve runtime performance? Compilation performance?
Will it reduce the size of the firefox package? anything else?

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.6 | | 651 bytes | |
Benjamin Smedberg wrote:
The Firefox trunk build will be changing to use by default
sometime early next week. This should not (knock on wood) have any
user-visible effects, but it will have some consequences for development:

1) xpcom_core.{dll,so,dylib} will no longer exist, it will be rolled into
the larger xul.dll/libxul.so/XUL library.

This happened around the 20060809 nightly build then got backed out,
right? (bug 345517)

I and some other nightly users had problems starting that build, see

Good luck next time!

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.7 | | 659 bytes | |
Benjamin Smedberg wrote:

2) the "internal linkage" functions are not exported from libxul, so it
will no longer be possible to compile extension code using internal
linkage (if you don't know what this means, see the linkage descriptions
at ).

that xpcom_glue page I see do_CreateInstance in a couple of examples.
But I don't see anything anywhere that says that do_CreateInstance and
do_GetService are frozen. Are they safe or not? If they are, what is
the best way to determine if I can use a function or not?

Thanks,

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.8 | | 540 bytes | |
Aaron Reed wrote:

that xpcom_glue page I see do_CreateInstance in a couple of examples.
But I don't see anything anywhere that says that do_CreateInstance and
do_GetService are frozen. Are they safe or not? If they are, what is
the best way to determine if I can use a function or not?

They are not frozen, but they are safe. This is because they are provided by
the glue library which is statically linked to your code.

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.9 | | 900 bytes | |
So is it safe to say that I can use any function in any header file in
mozilla/xpcom/glue? would you recommend I check against the list of
of all the exported functions in the glue library? Up until now I
assumed we could only use things mentioned in:

Thanks,

Benjamin Smedberg wrote:
Aaron Reed wrote:

>that xpcom_glue page I see do_CreateInstance in a couple of
>examples. But I don't see anything anywhere that says that
>do_CreateInstance and do_GetService are frozen. Are they safe or
>not? If they are, what is the best way to determine if I can use a
>function or not?

They are not frozen, but they are safe. This is because they are
provided by the glue library which is statically linked to your code.

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org
No.10 | | 460 bytes | |
Aaron Reed wrote:
So is it safe to say that I can use any function in any header file in
mozilla/xpcom/glue? would you recommend I check against the list of

I would hope that's true. It's "supposed" to be true.

of all the exported functions in the glue library? Up until now I

Well, if it doesn't link, then don't use it ;-)

dev-builds mailing list
dev-builds (AT) lists (DOT) mozilla.org

Re: Firefox build changing to --enable-libxul

EMSDN.COM

Question 'Firefox build changing to --enable-libxul' on 'Mozilla'

Mozilla

Firefox build changing to --enable-libxul