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)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: birtles, Assigned: ehsan.akhgari)

References

Details

Attachments

(2 files, 1 obsolete file)

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)
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.
Attached patch Patch (v1)Splinter Review
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+
Whiteboard: [needs landing]
Whiteboard: [needs landing]
Attached patch For check-inSplinter Review
Attachment #489477 - Flags: approval2.0?
Attachment #489477 - Flags: approval2.0? → approval2.0+
Whiteboard: [needs landing]
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.
http://hg.mozilla.org/mozilla-central/rev/da0ea0a5c3ac
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
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.
Anyone cross-compiling without fakelibs will need to update dlldeps.cpp too.
(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?
Blocks: 603679
Depends on: 612167
(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.)
Depends on: 612356
(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.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.