Firefox build changing to --enable-libxul
Benjamin Smedberg
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
http://developer.mozilla.org/en/docs/XPCOM_Glue).
3) developers who are hacking the core code will want to add
--disable-libxul 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 --disable-libxul flag to your development-tree
mozconfig now, you don't have to wait until next week's landing.
--BDS
Lev Serebryakov
Friday, August 4, 2006, 6:07:16 PM, you wrote:
BS> 2) the "internal linkage" functions are not exported from libxul, so it will
BS> no longer be possible to compile extension code using internal linkage
xpctools can not be build on Win32 after latest code update.
I've used `--enable-libxul' for long time without problems, and today got these errors:
make[6]: Entering directory `/cygdrive/d/Home/lev/xulrunner/mozilla/_obj-xulrunner-i686-pc-cygwin/js/src/xpconnect/tools/src'
/cygdrive/d/Home/lev/xulrunner/mozilla/build/cygwin-wrapper link -NOLOGO -DLL -OUT:xpctools.dll -PDB:xpctools.pdb -SUBSYSTEM:WINDOWS nsXPCToolsCompiler.obj nsXPCToolsProfiler.obj nsXPCToolsModule.obj ./module.res -IMPLIB:fake.lib ../../../../../dist/lib/xpcom.lib ../../../../../dist/lib/xul.lib ../../../../../dist/lib/nspr4.lib ../../../../../dist/lib/plc4.lib ../../../../../dist/lib/plds4.lib ../../../../../dist/lib/js3250.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 nsCOMPtr_base::~nsCOMPtr_base(void)" (??1nsCOMPtr_base@@QAE@XZ) referenced in function "public: __thiscall nsCOMPtr<class nsISupports>::~nsCOMPtr<class nsISupports>(void)" (??1?$nsCOMPtr@VnsISupports@@@@QAE@XZ)
nsXPCToolsProfiler.obj : error LNK2001: unresolved external symbol "public: __thiscall nsCOMPtr_base::~nsCOMPtr_base(void)" (??1nsCOMPtr_base@@QAE@XZ)
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: static void const * const nsObsoleteACString::sCanonicalVTable" (?sCanonicalVTable@nsObsoleteACString@@2PBXB) referenced in function "protected: __thiscall nsACString_internal::nsACString_internal(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 nsCOMPtr_base::assign_from_gs_contractid_with_error(class nsGetServiceByContractIDWithError const &,struct nsID const &)" (?assign_from_gs_contractid_with_error@nsCOMPtr_base@@QAIXABVnsGetServiceByContractIDWithError@@ABUnsID@@@Z) referenced in function "public: __thiscall nsCOMPtr<class nsIProperties>::nsCOMPtr<class nsIProperties>(class nsGetServiceByContractIDWithError const &)" (??0?$nsCOMPtr@VnsIProperties@@@@QAE@ABVnsGetServiceByContractIDWithError@@@Z)
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: void __fastcall nsCOMPtr_base::assign_from_qi(class nsQueryInterface,struct nsID const &)" (?assign_from_qi@nsCOMPtr_base@@QAIXVnsQueryInterface@@ABUnsID@@@Z) referenced in function "public: __thiscall nsCOMPtr<class nsILocalFile>::nsCOMPtr<class nsILocalFile>(class nsQueryInterface)" (??0?$nsCOMPtr@VnsILocalFile@@@@QAE@VnsQueryInterface@@@Z)
nsXPCToolsCompiler.obj : error LNK2019: unresolved external symbol "public: void __fastcall nsCOMPtr_base::assign_from_gs_cid_with_error(class nsGetServiceByCIDWithError const &,struct nsID const &)" (?assign_from_gs_cid_with_error@nsCOMPtr_base@@QAIXABVnsGetServiceByCIDWithError@@ABUnsID@@@Z) referenced in function "public: __thiscall nsCOMPtr<class nsIXPConnect>::nsCOMPtr<class nsIXPConnect>(class nsGetServiceByCIDWithError const &)" (??0?$nsCOMPtr@VnsIXPConnect@@@@QAE@ABVnsGetServiceByCIDWithError@@@Z)
nsXPCToolsProfiler.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __thiscall nsHashKey::Write(class nsIObjectOutputStream *)const " (?Write@nsHashKey@@UBEIPAVnsIObjectOutputStream@@@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@@PAX1@Z1@Z) referenced in function "public: void __thiscall ProfilerFile::EnumerateFunctions(int (__cdecl*)(class nsHashKey *,void *,void *),void *)" (?EnumerateFunctions@ProfilerFile@@QAEXP6AHPAVnsHashKey@@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@@PAUJSScript@@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@@PAUJSStackFrame@@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::FindOrAddFunction(char const *,unsigned int,unsigned int,unsigned int)" (?FindOrAddFunction@ProfilerFile@@QAEPAVProfilerFunction@@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@@PBDIPAUJSScript@@PAUJSFunction@@PAX@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: __thiscall nsCStringKey::nsCStringKey(char const *,int,enum nsCStringKey::Ownership)" (??0nsCStringKey@@QAE@PBDHW4Ownership@0@@Z) referenced in function "void __cdecl xpctools_JSNewScriptHook(struct JSContext *,char const *,unsigned int,struct JSScript *,struct JSFunction *,void *)" (?xpctools_JSNewScriptHook@@YAXPAUJSContext@@PBDIPAUJSScript@@PAUJSFunction@@PAX@Z)
nsXPCToolsProfiler.obj : error LNK2019: unresolved external symbol "public: void __fastcall nsCOMPtr_base::assign_from_gs_contractid(class nsGetServiceByContractID,struct nsID const &)" (?assign_from_gs_contractid@nsCOMPtr_base@@QAIXVnsGetServiceByContractID@@ABUnsID@@@Z) referenced in function "public: __thiscall nsCOMPtr<class nsIJSRuntimeService>::nsCOMPtr<class nsIJSRuntimeService>(class nsGetServiceByContractID)" (??0?$nsCOMPtr@VnsIJSRuntimeService@@@@QAE@VnsGetServiceByContractID@@@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@@PAPAVnsIModule@@@Z) referenced in function _NSGetModule
xpctools.dll : fatal error LNK1120: 18 unresolved externals
--
Best regards,
Lev mailto:l...@serebryakov.spb.ru
Benjamin Smedberg
> xpctools can not be build on Win32 after latest code update.
> I've used `--enable-libxul' for long time without problems, and today got these errors:
I have never built with --enable-xpctools. I suggest you file a bug (and fix
it!). Basically you'll have to change the xpctools code to not use
MOZILLA_INTERNAL_API.
The immediate cause of this change was this checkin:
--BDS
Aaron Leventhal
> 3) developers who are hacking the core code will want to add
> --disable-libxul 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 --disable-libxul 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
Benjamin Smedberg
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 --enable-libxul setting.
--BDS
steve....@gmail.com
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? Or anything else?
skie...@gmail.com
> The Firefox trunk build will be changing to use --enable-libxul 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
http://forums.mozillazine.org/viewtopic.php?t=449851
Good luck next time!
Aaron Reed
>
> 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 http://developer.mozilla.org/en/docs/XPCOM_Glue).
>
>
> --BDS
On 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,
--Aaron
Benjamin Smedberg
> On 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.
--BDS
Aaron Reed
mozilla/xpcom/glue? Or 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:
http://developer.mozilla.org/en/docs/XPCOM_API_Reference.
Thanks,
--Aaron
Benjamin Smedberg
> So is it safe to say that I can use any function in any header file in
> mozilla/xpcom/glue? Or 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 ;-)
--BDS