Closed
Bug 610556
Opened 14 years ago
Closed 14 years ago
Linker errors on shared builds with NS_SetDllDirectory
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla2.0b8
People
(Reporter: birtles, Assigned: ehsan.akhgari)
References
Details
Attachments
(2 files, 1 obsolete file)
3.41 KB,
patch
|
khuey
:
review+
|
Details | Diff | Splinter Review |
3.55 KB,
patch
|
benjamin
:
approval2.0+
|
Details | Diff | Splinter Review |
Attempting a non-libxul build on Windows is giving me the following linker error: c:\moz\src\config\rules.mk:1358:0$ link -NOLOGO -DLL -OUT:gkplugin.dll -PDB:gkpl ugin.pdb -SUBSYSTEM:WINDOWS nsNPAPIPlugin.obj nsNPAPIPluginInstance.obj nsNPAPI PluginStreamListener.obj nsPluginStreamListenerPeer.obj nsPluginHost.obj nsPlugi nModule.obj nsJSNPRuntime.obj nsPluginTags.obj PluginPRLibrary.obj nsPluginsDirW in.obj nsPluginNativeWindowWin.obj nsPluginDirServiceProvider.obj ./module.re s -NXCOMPAT -DYNAMICBASE -SAFESEH -DEBUG -DEBUGTYPE:CV -IMPLIB:fake.lib ../.. /../../dist/lib/gkgfx.lib c:/moz/src/obj-debug/dist/lib/unicharutil_s.lib c:/mo z/src/obj-debug/dist/lib/xpcom.lib c:/moz/src/obj-debug/dist/lib/xpcom_core.lib c:/moz/src/obj-debug/dist/lib/mozalloc.lib c:/moz/src/obj-debug/dist/lib/nspr4.l ib c:/moz/src/obj-debug/dist/lib/plc4.lib c:/moz/src/obj-debug/dist/lib/plds4.li b c:/moz/src/obj-debug/dist/lib/mozjs.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib version.lib Creating library fake.lib and object fake.exp nsPluginsDirWin.obj : error LNK2019: unresolved external symbol __imp__NS_SetDll Directory referenced in function "public: unsigned int __thiscall nsPluginFile:: LoadPlugin(struct PRLibrary * *)" (?LoadPlugin@nsPluginFile@@QAEIPAPAUPRLibrary@ @@Z) gkplugin.dll : fatal error LNK1120: 1 unresolved externals c:\moz\src\config\rules.mk:1358:0: command 'link -NOLOGO -DLL -OUT:gkplugin.dll -PDB:gkplugin.pdb -SUBSYSTEM:WINDOWS nsNPAPIPlugin.obj nsNPAPIPluginInstance.ob j nsNPAPIPluginStreamListener.obj nsPluginStreamListenerPeer.obj nsPluginHost.ob j nsPluginModule.obj nsJSNPRuntime.obj nsPluginTags.obj PluginPRLibrary.obj nsPl uginsDirWin.obj nsPluginNativeWindowWin.obj nsPluginDirServiceProvider.obj ./ module.res -NXCOMPAT -DYNAMICBASE -SAFESEH -DEBUG -DEBUGTYPE:CV -IMPLIB:fake.l ib ../../../../dist/lib/gkgfx.lib c:/moz/src/obj-debug/dist/lib/unicharutil_s. lib c:/moz/src/obj-debug/dist/lib/xpcom.lib c:/moz/src/obj-debug/dist/lib/xpcom_ core.lib c:/moz/src/obj-debug/dist/lib/mozalloc.lib c:/moz/src/obj-debug/dist/li b/nspr4.lib c:/moz/src/obj-debug/dist/lib/plc4.lib c:/moz/src/obj-debug/dist/lib /plds4.lib c:/moz/src/obj-debug/dist/lib/mozjs.lib kernel32.lib user32.lib g di32.lib winmm.lib wsock32.lib advapi32.lib version.lib ' failed, return code 1 120 c:\moz\src\config\rules.mk:952:0: command 'c:/mozilla-build/python/python.exe c: /moz/src/build/pymake/pymake/../make.py -C base/src libs' failed, return code 2 c:\moz\src\config\rules.mk:782:0: command 'c:/mozilla-build/python/python.exe c: /moz/src/build/pymake/pymake/../make.py -C modules/plugin libs' failed, return c ode 2 c:\moz\src\config\rules.mk:793:0: command 'c:/mozilla-build/python/python.exe c: /moz/src/build/pymake/pymake/../make.py libs_tier_platform' failed, return code 2 c:\moz\src\config\rules.mk:743:0: command 'c:/mozilla-build/python/python.exe c: /moz/src/build/pymake/pymake/../make.py tier_platform' failed, return code 2 c:\moz\src\client.mk:345:0: command 'c:/mozilla-build/python/python.exe c:/moz/s rc/build/pymake/pymake/../make.py -C ../obj-debug' failed, return code 2 Attempting to 'make' in toolkit/xre gives me: nsSetDllDirectory.cpp c:/mozilla-build/python/python2.6.exe -O c:/moz/src/build/cl.py cl -FonsSetDllDi rectory.obj -c -D_HAS_EXCEPTIONS=0 -I../../dist/stl_wrappers -DIMPL_XREAPI -DMO Z_APP_NAME='"firefox"' -DMOZ_UPDATER -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -DMOZILLA_INTERNAL_API -DOSTYPE=\"WINNT5.1\" -DOSARCH=WINNT -DOS_TARGET=\"WINNT\ " -DMOZ_WIDGET_TOOLKIT=\"windows\" -DTARGET_XPCOM_ABI=\"x86-msvc\" -DTARGET_OS_A BI=\"WINNT_x86-msvc\" -DTOOLKIT_EM_VERSION=\"2.0b8pre\" -DGRE_MILESTONE=2.0b8pr e -DGRE_BUILDID=20101109091102 -I../../../dom/ipc -I../../../toolkit/crashreport er -I../../../toolkit/xre -I../../../toolkit/xre/../profile/src -I../../../conf ig -I../../../toolkit/xre -I. -I../../dist/include -I../../dist/include/nsprpub -Ic:/moz/src/obj-debug/dist/include/nspr -Ic:/moz/src/obj-debug/dist/include/n ss -GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -wd4800 -DDEB UG -D_DEBUG -DTRACING -Zi -MDd -FI ../../dist/include/mozilla-confi g.h -DMOZILLA_CLIENT /c/moz/src/toolkit/xre/nsSetDllDirectory.cpp nsSetDllDirectory.cpp c:/moz/src/toolkit/xre/nsSetDllDirectory.cpp(50) : error C2491: 'mozilla::NS_Set DllDirectory' : definition of dllimport function not allowed make[1]: *** [nsSetDllDirectory.obj] Error 2 make[1]: Leaving directory `/c/moz/src/obj-debug/toolkit/xre' make: *** [all] Error 2 My mozconfig: . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-debug ac_add_options --disable-optimize ac_add_options --enable-debug ac_add_options --enable-tests ac_add_options --disable-libxul ac_add_options --disable-static ac_add_options --disable-ipc ac_add_options --disable-crashreporter ac_add_options --disable-accessibility ac_add_options --enable-chrome-format=jar This seems to be introduced by changeset: http://hg.mozilla.org/mozilla-central/rev/413f719c1d73 As suggested by Ehsan, for the time being I have just made NS_SetDllDirectory inline and it seems to be building ok. (See attached patch)
Assignee | ||
Comment 1•14 years ago
|
||
I would guess that adding EXTRA_DSO_LIBS += xulapp_s to modules/plugins/Makefile.in should have solved this, but it doesn't. Brian told me that by the time that we try to build gkplugin.dll, xulapp library has not been built. I'd appreciate any help from the build system peers on how we should setup the correct build dependencies...
QA Contact: general → build-config
The right thing to do here is move NS_SetDllDirectory into xpcom/.
Also, the double namespacing on this function is suboptimal.
Assignee | ||
Comment 4•14 years ago
|
||
This seems to fix the problem.
Assignee: nobody → ehsan
Attachment #489058 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #489375 -
Flags: review?(khuey)
Comment on attachment 489375 [details] [diff] [review] Patch (v1) Either export the header to mozilla/nsSetDLLDirectory.h or do the LOCAL_INCLUDES gunk, but not both. >+ifeq (windows,$(MOZ_WIDGET_TOOLKIT)) >+CPPSRCS += nsSetDllDirectory.cpp >+EXPORTS_mozilla += nsSetDllDirectory.h >+endif >+ Lose the hard tabs you're adding. r=me with that.
Attachment #489375 -
Flags: review?(khuey) → review+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs landing]
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs landing]
Assignee | ||
Comment 6•14 years ago
|
||
Attachment #489477 -
Flags: approval2.0?
Updated•14 years ago
|
Attachment #489477 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs landing]
Comment 7•14 years ago
|
||
The patch seems to break desktop debug Fennec build on my XP box: d:/mozilla/mozilla-central/dom/plugins/PluginProcessChild.cpp(56) : fatal error C1083: Cannot open include file: 'nsSetDllDirectory.h': No such file or directory It was a clobbered build.
dom/plugins/Makefile.in probably needs a sprinkling of the LOCAL_INCLUDES stuff.
Assignee | ||
Comment 9•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/da0ea0a5c3ac
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
Comment 10•14 years ago
|
||
Fix comm-central too: http://hg.mozilla.org/comm-central/rev/690fef3920f8 Bustage fix from bug 610556 (Linker errors on shared builds with NS_SetDllDirectory) landing on m-c. + http://hg.mozilla.org/comm-central/rev/f8980d547f1e (Dv1-CC) s/topsrcdir/MOZILLA_SRCDIR/, Fix Sunbird too.
Comment 11•14 years ago
|
||
Anyone cross-compiling without fakelibs will need to update dlldeps.cpp too.
Assignee | ||
Comment 12•14 years ago
|
||
(In reply to comment #11) > Anyone cross-compiling without fakelibs will need to update dlldeps.cpp too. Is it a simple matter of adding a dummy call to mozilla::NS_SetDllDirectory there?
Comment 13•14 years ago
|
||
(In reply to comment #12) > (In reply to comment #11) > > Anyone cross-compiling without fakelibs will need to update dlldeps.cpp too. > Is it a simple matter of adding a dummy call to mozilla::NS_SetDllDirectory > there? I added it locally after the call to NS_NewWindowsRegKey. (And I added the include after the nsWindowsRegKey include too, for consistency.) (Also note that there's already a "using namespace mozilla;" statement in the file.)
Assignee | ||
Comment 14•14 years ago
|
||
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Anyone cross-compiling without fakelibs will need to update dlldeps.cpp too. > > Is it a simple matter of adding a dummy call to mozilla::NS_SetDllDirectory > > there? > I added it locally after the call to NS_NewWindowsRegKey. (And I added the > include after the nsWindowsRegKey include too, for consistency.) (Also note > that there's already a "using namespace mozilla;" statement in the file.) Filed bug 612356 for that.
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•