(Answer) (Category) OpenLDAP Faq-O-Matic : (Category) OpenLDAP Developer's FAQ : (Category) Porting OpenLDAP : (Category) Porting to IBM OS/390 : (Answer) Building Cyrus SASL 2
Cyrus SASL 2.1.7 does not build easily on OS/390. The existing build procedures are heavily oriented toward a platform with "mainstream" dynamic library support. Since libtool doesn't handle OS/390 DLLs, many compilation errors result from trying to build this package.

Given the very daunting screenfuls of error messages, I initially scaled back to just trying to build a static library with SASL/EXTERNAL. Even this was difficult as the build procedures really are set up to create shared libraries. After patching the Makefiles to produce usable static libraries, and building the libsasl2 code in ASCII mode, I was able to use SASL/EXTERNAL to perform X.509-based authentication with slapd.

I have since submitted a large number of patches back to Cyrus to clean up most of the portability issues and streamline the build. These patches should be available soon in the Cyrus CVS repository, maybe for release in 2.1.8. With those patches in place, you should be able to build the package a lot more easily.

To build the patched source, you should use the acc (ASCII cc) script that you used to compile OpenLDAP. You'll need these environment variables, at a minimum:

    _C89_CCMODE=1
    CC=acc
    CPP="c89 -E"
    LD=c89
    CPPFLAGS=-D_ALL_SOURCE
That should allow you to run configure and get a coherent build environment. Before you type "make" from the top level though, do this:
    cd include
    make CC=c89
In the include directory is a small program that generates an md5global.h header file. This file must be generated in native EBCDIC. If you just typed make from the top level, the program and header file would be generated in ASCII, with an ASCII filename, which would be very confusing and not very useful.

I have subsequently tested the DIGEST-MD5 mechanism, using slapd itself for storage of the secrets. It worked without any trouble. Note, I configured sasl --with-dblib=none to prevent it from trying to use its own sasldb. This is simply because I haven't had the time to fix the EBCDIC/ASCII dependencies in the rest of the SASL library. Run as-is with a real database backend, the sasldb would try to create ASCII-named database files, which would be very unpleasant. The required fixes are trivial, but they are also numerous, and it is a very time-consuming task to track down all the dependencies.

In contrast to the Berkeley DB port and OpenSSL port, which both can be used perfectly well on their own/with other OS/390 software, this minimal-effort port of SASL will only work in the context of OpenLDAP. Since no effort has been made to fix the ASCII filenames in the library, this SASL library will be unable to create/parse/handle native config files or database files. This is why I've only tested it using secrets stored in slapd, and why I only tried SASL/EXTERNAL at first. (EXTERNAL has no config parameters, and is part of libsasl2 itself, so it doesn't need to be dynamically loaded from anywhere.)

Feel free to email me if you have more questions or information on using Cyrus SASL on OS/390.
hyc@openldap.org

[Append to This Answer]
Previous: (Answer) Building OpenSSL
This document is: http://www.openldap.org/faq/index.cgi?file=755
[Search] [Appearance]
This is a Faq-O-Matic 2.721.test.
© Copyright 1998-2013, OpenLDAP Foundation, info@OpenLDAP.org