Patrick wrote:
> 
> Nelson,
> 
> I don't have a libsectool.a anymore since NSS 3.3 now provides only 3 shared
> libs (nss3.dll, smime3.dll, ssl3.dll)

Ah, then apparently you're not building NSS yourself from sources.

> Do I need to build a custom  NSS 3.3 to export functions that are now
> internal? 

It's not a matter of exporting.  The functions aren't in the libs you named.

> Which NSS build file do I need to tweak the directives for export
> NSS functions?

The SECU_ functions are not "internal" to the 3 DLLs you named above.
There's no way to "export" those functions from any of those libs, because
they're not in those libs at all.  The SECU_ functions are all part of the 
code in nss/cmd/lib, that is, those functions are part of NSS's commands, 
not NSS's libraries.   

Let me try to explain that better.  (The following is my personal view.)

NSS is fundamentally divided into "libraries" and "commands" (utilities
and test programs).  The libraries are in nss/lib and the commands are in
nss/cmd.  The distinction between them has primarily to do with how the 
code is supported.  Public library functions are supported for use in other 
Netscape products and by other third party programs (such as yours).  
We take bug reports against individual functions in the libraries.  The
"commands" are only supported as whole programs.  We take bug reports against
the operation of the programs, but not against the individual internal 
functions inside those commands.  The functions in those commands simply 
are not intended to be used by other software.  In some cases, the commands 
use deprecated interfaces that are not supported.  

There is a set of code that is common to many of the commands.  That 
common code has been made into a library, but the code in that library is 
only supported as part of the commands, not as a separate library for use 
by third party programs.  That library of common command code is found in
nss/cmd/lib (not nss/lib), and is built into libsectool.a on Unix and into
sectool.lib on Windows (that is, it's not a shared lib).  That library is 
linked into the commands, but the built library is not shipped along with 
the commands or NSS libraries.  Not even Netscape's own server products link
with the sectool library!

All the code in nss/cmd/lib is under the mozilla public license.  You're 
welcome to use the source code in nss/cmd/lib in any way allowed by the MPL.
You could use it as "example" code, (although some of it is hardly exemplary),  
or compile sectool.lib (or a single part of it such as strerror.obj) yourself 
and call the compiled functions in your own programs.  But please understand
that this code is not supported in the same way as the functions in the NSS
libraries (DLLs) named above.  If you use this code, you support it yourself.

Now, in re-reading what I just wrote, I realize that it sounds like I'm 
making an official policy statement.  I'm not.  (see disclaimer below) 
I'm merely stating my own understanding of the difference between those 
two sets of code (cmd and lib), as I've come to understand it over the 
last 5 years.  

I hope this explains why the code you want is not available in the same way
as the other library functions that you use.

--
Nelson Bolyard               Netscape 
Disclaimer:                  I speak for myself, not for Netscape

Reply via email to