Paul Neyman wrote: > Thanks for the quick reply. Let me clear up myself. Here's what's > happening:
>>> 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? > > It was listed in the header under /private, so I assumed it's not. > Thanks for clearing this up. I don't think it's cleared up yet. There are many different meanings for the terms "public" and "private". The linker uses "public" to mean "available in this library to resolve symbolic references from other binaries that are linked with this library." In that sense, all the symbols in sectool are public. Another use of "public" and "private" involves the intentions of the software developers. In that sense, "public" means "the software developers intended for other people (other software) to use this symbol" and "private" means "the software developers intended for this symbol to be only used by NSS itself, internally, and did NOT intend for this symbol to be used by any code outside of NSS itself". Any time you see comments in a header file about a function being private, or you see a symbol defined in a header file in a directory named private, it refers to the latter meaning, the intentions and permissions of the NSS software developers. When the NSS developers declare a symbol to be private, they are saying that at any time, in any future release, they may remove or redefine that symbol, without warning or advanced notice. Any problem that you have when they do so is not their problem. So, it's best not to use symbols that the developers have declared private. Some symbols are "public" in the linker's sense of that word, but are "private" in the sense of the developers intentions. All the symbols in sectool are that way, IIRC. You said that you were having linking troubles. That sounds like you are saying that the linker believed the symbols were not "public" in the linker's definition of that word. That would be very surprising indeed, because, as I wrote before, sectool is not a shared library, and consequently there is no way for any of its internal symbols to be made private (in the linker's sense of that term). All its symbols are publicly linkable (as far as the linker is concerned, having nothing to do with developers' intentions). >> What problem are you having linking with sectool.lib? >> What error do you get? > > If I link sectool and nss3 (for other calls my application does) during > linking stage, I get a bunch of errors about method redefinitions > (already defined in nss3) and I get an error about MSVCRT conflicting > with use of other libs. > > secutil.lib(secoid.obj) : error LNK2005: _SECOID_FindOID already defined > in nss3.lib(nss3.dll) Wait. that error message doesn't mention sectool. It mentions secutil.lib. You shouldn't be linking in secutil.lib. secutil.lib is part of nss3.dll. > secutil.lib(secasn1d.obj) : warning LNK4006: _SEC_ASN1DecodeItem already > defined in nss3.lib(nss3.dll); second definition ignored Yeah, you definitely should not be linking in any of the .lib files that are components of nss3.dll into your code. You should be linking nss3.lib (for the purpose of using nss3.dll). Now, what do these secutil issues have to do with sectool.lib? > LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other > libs; use /NODEFAULTLIB:library Sounds to me like you're trying to link in a LOT more than sectool and nss3. Take a look at how the command tools in nss/cmd/* are linked. Trying building some of them, and follow the examples of the link commands they use. That's my suggestion. -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
