"Anton Bobrov" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>
> Dennis Darch wrote:
>
>> First question:  Is building from the 1.7.13 source tar-ball the best 
>> approach for using the C SDK for LDAP support with and without SSL on 
>> these three platforms?
>
> the best approach would be to use the latest standalone C SDK, see :
> http://wiki.mozilla.org/LDAP_C_SDK#Checking_Out_the_Source_Code
>
>> Second question:  If this is the right approach, what do I need to do to 
>> get it to compile?  Here is what I have done so far, working on Windows 
>> first. (Previous, non-SSL experience showed that building on UNIX is a 
>> snap once I get Windows to work.)
>
> there some doze related quirks outlined on the wiki link above so
> make sure you read thru before building.

Thank you for your suggestions.  I switched to using the current released 
source code (i.e. mozldap-6.0.4.tar.gz and nss-3.11.9-with-nspr-4.7.tar.gz), 
and managed to get them to compile and work.

On UNIX, the instructions on http://wiki.mozilla.org/LDAP_C_SDK were all I 
needed (plus BUILD_OPT=1 and "--enable-optimize --disable-debug" to produce 
non-debug versions).  But on Windows I did have to work around three 
problems.  I am documenting those problems here, in case someone else needs 
the information and/or the developers wish to address them.  (I am not 
familiar with Bugzilla;  someone on the development teams will have to enter 
these problems into their system.)

First problem: Compiling in NSS
Both mozilla/nsprpub/config/rules.mk and mozilla/security/coreconf/rules.mk 
note that the compiler has to be given absolute paths so that the debuggers 
on Windows and OS/2 will be able to automatically locate the source files. 
But if gmake simply launches the MSVC 6.0 compiler with the standard 
Cygwin-style absolute paths (e.g. /cygdrive/c/.../foo.c ) then the command 
line parser makes the compiler think that this is an unrecognized 
option/switch argument rather than a source file.  In NSPRPUB this problem 
is avoided by running the compiler via the cygwin-wrapper script, so that 
the absolute path is no longer Cygwin-style.  But in NSS this is not done, 
so compilation fails.

My work-around:  Since I was building the libraries without debug anyway, I 
decided to compile without using absolute paths.  I did this by editing the 
four compile rules in mozilla/security/coreconf/rule.mk.  This would not be 
an acceptable approach for NSS developers, of course.

Second problem:  Signing shared NSS libraries
After building the shared libraries, several of them are signed with the 
tool built in mozilla/security/nss/cmd/shlibsign.  The Makefile invokes the 
shlibsign program via script sign.sh in that directory.  But gmake 
identifies the shared library files that are to be signed using Cygwin-style 
absolute paths, while the shlibsign program calls a NSPRPUB routine that 
opens the file using a native Windows API that does not accept such paths. 
As a result, the attempt to sign the library files fails.

My work-around:  Edit mozilla/security/nss/cmd/shlibsign/sign.sh so that the 
line that launches shlibsign will run it via 
../../../../../nsprpub/build/cygwin-wrapper.  This changes the Cygwin-style 
path into a classical Windows style path (e.g. C:/.../foo.dll), so the 
library files can be signed successfully.

Third problem:  Incompatibility between Netscape gmake and Active Perl 
v5.8.8
The Makefile for the C SDK uses Perl to generate ldap-standard.h.  There is 
some incompatibility between my version of gmake (which I got from 
http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools.zip) and my 
version of Perl (which is Active Perl v5.8.8).  When gmake launches the Perl 
command, it hangs.

My work-around:  Interrupt the hung program via Ctrl+C, copy-and-paste the 
Perl command onto the command line, then resume the build.  The total build 
sequence becomes:
cd mozilla/directory/c-sdk
configure --with-nss --enable-optimize --disable-debug
gmake
<Ctrl+C>
pushd ldap/include
perl ./../build/replace.pl LDAP_VENDOR_NAME="mozilla.org" 
LDAP_VENDOR_VERSION="604" < ldap-standard-tmpl.h > 
../../../../dist/public/ldap/ldap-standard.h
popd
gmake


_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap

Reply via email to