Rich Megginson wrote:
Steve Parkinson wrote:
I've been playing with SWIG a little. It seems too easy!
My comments so far:
1) Private function definitions. SWIG can make wrapper functions for all
functions declared in the header files. But, not all of those end up
being exposed in the .so, (due to nss.def). You really need to
explicitly list the functions in your API that you want to expose, to
avoid run time linker problems.
I think it would be better if all functions not in nss.def are moved to
private header files, which are only #included if NSS_PRIVATE is
defined. This would also have the benefit of a) not confusing people
about the API, and b) helping the compiler catch errors, instead of the
linker.
Is this required to "SWIG" NSS for use in scripting languages? Or is it
just that it would be nice to have these private functions also exposed
to the scripting language?
I don't want the private functions exposed to the scripting language.
It was just easy to make SWIG look at the existing header files - but
that causes all these unresolved symbols.
Instead, we'd have to just compose a list of only the symbols we want
exposed. So, nothing needs to be done in NSS, but separating the private
api out would be nice anyway for the a&b reasons above.
also: Tiny error in my build.sh file caused by bad cut&paste:
gcc -I ../../Linux2.6_x86_glibc_PTH_DBG.OBJ/include/ -c nss_wrap.c \
`perl -MExt Utils::Embed -e ccopts`
should be:
gcc -I ../../Linux2.6_x86_glibc_PTH_DBG.OBJ/include/ -c nss_wrap.c \
`perl -MExtUtils::Embed -e ccopts`
Steve
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
