[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
