[EMAIL PROTECTED] wrote: > I'm trying to import a CRL (in DER format) using NSS API. Since 3.4 API > does not have an import function available,
You're using NSS 3.4? The current NSS is 3.11 . I think 3.4 is no longer supported. > I took the source code from > the crlutil and massaged it to fit into our application. That sounds resourceful, but I'd be surprised if you can achieve what you want with NSS 3.4. > The crlutil code, however, uses method SECU_ReadDERFromFile, which is > not exported as public, and I get a failure during linking stage trying > to use sectool.lib. Um, it's not? ALL the non-static functions in sectool.lib are public (in the linker's sense of that word). Since sectool is not a DLL, no .def file is relevant, and no function names are hidden. sectool is not a shared library, not a dll. sectool.lib is not a set of stub functions for accessing a DLL, that is, it is not an "export lib" (as would be the case if sectool was a DLL). The command dumpbin /EXPORTS sectool.lib doesn't show any symbols, because there aren't any DLL exports in it. sectool.lib contains the actual code for the library's functions. The command dumpbin /symbols sectool.lib shows the names of all the functions in sectool. The command dumpbin /SYMBOLS sectool.lib | fgrep SECU_Read outputs 101 00000EC9 SECT6 notype () External | _SECU_ReadDERFromFile > What's the easiest way to make this function publicly available? It already is. it's in sectool.lib, not nss.lib. > I tried modifying nss.def in nss/lib/nss, That .def file is for producing nss.lib, the export library file for nss3.dll. But the function you want is not part of nss3.dll, so nss.def has no relevance to this issue. > but I'm not sure how to link sectool during nss.lib build; Are you trying to alter some code in nss3.dll so that it calls SECU_ReadDERFromFile, and then link SECU_ReadDERFromFile into nss3.dll? If so, I'd suggest calling SECU_ReadDERFromFile from your application instead, and linking your application (not nss3.dll) with sectool.lib. > it seems to be built separately at a later stage. Yes. The code in sectool.lib is NOT for use in any NSS shared lib. > I'd appreciate any hints. What problem are you having linking with sectool.lib? What error do you get? Is this a function name mangling issue? Are you calling SECU_ReadDERFromFile from c++ code? If so, then this is likely a problem with the declaration of SECU_ReadDERFromFile in the header file. > Thanks. -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto