1133436 - SetDefaultDllDirectories and LOAD_LIBRARY_SEARCH_SYSTEM32 not found during Win32 build

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Edmund Wong (:ewong)]

while building 2.33b1, Win32 build went red:

e:/builds/slave/rel-c-beta-w32-bld/build/objdir/_virtualenv/Scripts/python.exe -m mozbuild.action.cl  cl -Fokern.obj -c -I../../../dist/stl_wrappers  -DPACKAGE_VERSION='"moz"' -DPACKAGE_BUGREPORT='"http://bugzilla.mozilla.org/"' -DNOMINMAX -DAB_CD=en-US -DNO_NSPR_10_SUPPORT -Ie:/builds/slave/rel-c-beta-w32-bld/build/mozilla/gfx/ots/src -I.  -I../../../dist/include   -Ie:/builds/slave/rel-c-beta-w32-bld/build/objdir/dist/include/nspr -Ie:/builds/slave/rel-c-beta-w32-bld/build/objdir/dist/include/nss        -MD            -FI ../../../dist/include/mozilla-config.h -DMOZILLA_CLIENT  -TP -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4482 -wd4800 -wd4819 -we4553 -GR-  -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -O1 -Oi -Oy   -Fdgenerated.pdb   e:/builds/slave/rel-c-beta-w32-bld/build/mozilla/gfx/ots/src/kern.cc
ltsh.obj
loaddlls.cpp
e:/builds/slave/rel-c-beta-w32-bld/build/mozilla/toolkit/mozapps/update/updater/loaddlls.cpp(24) : error C2065: 'SetDefaultDllDirectories' : undeclared identifier
e:/builds/slave/rel-c-beta-w32-bld/build/mozilla/toolkit/mozapps/update/updater/loaddlls.cpp(25) : error C2065: 'SetDefaultDllDirectories' : undeclared identifier
e:/builds/slave/rel-c-beta-w32-bld/build/mozilla/toolkit/mozapps/update/updater/loaddlls.cpp(27) : error C2065: 'LOAD_LIBRARY_SEARCH_SYSTEM32' : undeclared identifier
TestUniquePtr.cpp
e:/builds/slave/rel-c-beta-w32-bld/build/mozilla/config/rules.mk:934: recipe for target 'loaddlls.obj' failed
mozmake.exe[4]: Leaving directory 'e:/builds/slave/rel-c-beta-w32-bld/build/objdir/toolkit/mozapps/update/updater'
e:/builds/slave/rel-c-beta-w32-bld/build/mozilla/config/recurse.mk:74: recipe for target 'toolkit/mozapps/update/updater/target' failed
e:/builds/slave/rel-c-beta-w32-bld/build/objdir/_virtualenv/Scripts/python.exe -m mozbuild.action.cl  cl -Foltsh.obj -c -I../../../dist/stl_wrappers  -DPACKAGE_VERSION='"moz"' -DPACKAGE_BUGREPORT='"http://bugzilla.mozilla.org/"' -DNOMINMAX -DAB_CD=en-US -DNO_NSPR_10_SUPPORT -Ie:/builds/slave/rel-c-beta-w32-bld/build/mozilla/gfx/ots/src -I.  -I../../../dist/include   -Ie:/builds/slave/rel-c-beta-w32-bld/build/objdir/dist/include/nspr -Ie:/builds/slave/rel-c-beta-w32-bld/build/objdir/dist/include/nss        -MD            -FI ../../../dist/include/mozilla-config.h -DMOZILLA_CLIENT  -TP -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4482 -wd4800 -wd4819 -we4553 -GR-  -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -O1 -Oi -Oy   -Fdgenerated.pdb   e:/builds/slave/rel-c-beta-w32-bld/build/mozilla/gfx/ots/src/ltsh.cc
math.obj
mozmake.exe[4]: *** [loaddlls.obj] Error 2
mozmake.exe[3]: *** [toolkit/mozapps/update/updater/target] Error 2
mozmake.exe[3]: *** Waiting for unfinished jobs....

Looking at the code in toolkit/mozapps/update/updater/loaddlls.cpp:

19     HMODULE module = ::GetModuleHandleW(L"kernel32.dll");
20     if (module) {
21       // SetDefaultDllDirectories is always available on Windows 8 and above. It
22       // is also available on Windows Vista, Windows Server 2008, and
23       // Windows 7 when MS KB2533623 has been applied.
24       decltype(SetDefaultDllDirectories)* setDefaultDllDirectories =
25         (decltype(SetDefaultDllDirectories)*) GetProcAddress(module, "SetDefaultDllDirectories");
26       if (setDefaultDllDirectories) {
27         setDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32);
28         return;
29       }

This change was introduced in bug 945192 (which I have no access to), but
was apparently pushed with this cset: http://hg.mozilla.org/releases/mozilla-beta/rev/cf270a9a66ad on 29th Jan. 2015.

This change totally breaks our Win32 builders (since it's still on 2003) and
without (afaik) said MS KB applied.

This blocks 2.33b1 badly.  At this moment, I can only assume that backing out
this change (on a RELBRANCH) would work; but this is *way* too dangerous for 
me to attempt just on the assumption that said back-out would work (which,
I'm not confident that it would).

Comment 1

[Edmund Wong (:ewong)]

this was fixed by bug 945192.