Need help building LDAP C SDK with SSL support
Dennis Darch
Mozilla LDAP C SDK, but have not been able to build the libraries. I would
appreciate it if someone could point me in the right direction.
Background:
We have an application program, written in C, that we build on Solaris 8 (to
support 8, 9, and 10), HP-UX 11i, and Windows XP (to support 2000, XP, and
2003) using MS VC 6.0. About four years ago we added user password checking
via LDAP, calling ldap_simple_bind_s(). We downloaded the source tar-ball
for the Mozilla LDAP C SDK version 1.7.2 and built it on all three
platforms. We now want to add the option of connecting to the LDAP server
over SSL. So I have downloaded the version 1.7.13 tar-ball and tried to
build the libraries, following the instructions I found on the Web pages.
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?
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.)
What works - non-SSL:
1. Install Cygwin, but rename its link.exe to something else.
2. Download
http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools.zip and
install in C:\moztools.
3. Install MS Macro ASM 6.11 (just in case it turns out I need it)
4. Prepare command window for use:
4.1 Run VCVARS32.BAT to set path for running VC 6.0 components.
4.2 Run cygwin.bat
4.3 Source in a file that sets environment variables:
MOZ_TOOLS=C:\\moztools
export MOZ_TOOLS
PATH=${PATH}:/cygdrive/c/MASM611/BIN:/cygdrive/c/moztools/bin:/cygdrive/c/cygwin/bin:.
5. Unpack the source tar-ball by: tar -xvf mozilla-1.7.13-source.tar
6. Build and install NSPR:
6.1 Build it:
cd mozilla/nsprpub
configure --enable-optimize --disable-debug
gmake
cd pr/tests
gmake
cd ../../../..
6.2 Install the resulting files where they will be needed:
mkdir mozilla/dist/include
### copy the tree mozilla/nsprpub/dist/include/nspr to
mozilla/dist/include/nspr
mkdir mozilla/dist/lib
cp mozilla/nsprpub/dist/lib/* mozilla/dist/lib
7. Build the C SDK
7.1 First follow the instructions:
cd mozilla/directory/c-sdk
configure --enable-optimize --disable-debug
gmake
7.2 Compensate for incompatibility between gmake and Active Perl
### when the perl command that creates ldap-standard.h hangs,
interrupt it with Ctrl+C
cd ldap/include
### copy+paste the perl command and execute it
cd ../..
gmake
What fails - trying to include SSL
Steps 1 - 6 = same as above
7. Build and install NSS
7.1 Build:
cd mozilla/securitiy/nss
gmake nss_build_all
cd ../../..
7.2 Install the resulting files where they will be needed:
mkdir mozilla/dist/public mozilla/dist/public/securitiy
cp mozilla/security/nss/lib/*/*.h mozilla/dist/public/security
8. Build the C SDK
This is the same as non-SSL step 7 but with the addition of "--with-nss"
to the configure command.
The gmake dies after the link command that makes nsldapssl32v50.dll fails
with error:
LINK : fatal error LNK1181: cannot open input file
"../../../../../dist/lib/nss3.lib"
I thought this library would be produced by building in
mozilla/security/manager. So I did:
configure --enable-crypto
in the base mozilla directory and then went to mozilla/security/manager and
ran gmake, but that also fails.
Thank you in advance for help and advice.
Dennis Darch
SofTech, Inc.
Anton Bobrov
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.
Dennis Darch
"Anton Bobrov" <Anton....@Sun.COM> wrote in message
news:mailman.346.12113586...@lists.mozilla.org...
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
Nelson Bolyard
> 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.
[Long list of cygwin-related build issues snipped for brevity.]
The solution to these issues is: don't use cygwin.
cygwin is no longer the recommended build environment for Mozilla products
on Windows. Mozilla now offers a set of build tools based on MinGW that
work without all the headaches.
Regards,
/Nelson