Hi Cad, On Mon, Jul 19, 2010 at 10:56 AM, Caden.smith Smith <caden.smith...@gmail.com> wrote: > > Just for your information, here is the tree: > > JSS4.DLL > NSPR4.DLL > ADVAPI32.DLL > SECUR32.DLL > NETAPI32.DLL > DNSAPI.DLL > MPRAPI.DLL > SETUPAPI.DLL > SHELL32.DLL > SHDOCVW.DLL > MSHTML.DLL > IEFRAME.DLL that finally requires IESHIMS.DLL and WER.DLL
Thanks a lot. There is no unexpected dependency. NSPR4.DLL is known to depend on ADVAPI32.DLL. Here is the linker flag: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/Makefile.in&rev=1.57&mark=196,200#196 The symbols NSPR4.DLL imports from ADVAPI32.DLL have to do with access control for files: ADVAPI32.dll 1001D000 Import Address Table 100207C4 Import Name Table 0 time date stamp 0 Index of first forwarder reference 1F AllocateAndInitializeSid 72 CopySid 130 GetLengthSid 154 GetTokenInformation 1F1 OpenProcessToken 11A FreeSid 2B0 SetSecurityDescriptorDacl 10 AddAccessAllowedAce 170 InitializeAcl 2B1 SetSecurityDescriptorGroup 2B2 SetSecurityDescriptorOwner 171 InitializeSecurityDescriptor So I think the solution is most likely in figuring out the environment variable that controls the target Windows version for Windows SDK. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
