292793 - LDAP C SDK libraries and command-line tools don't build on OS X

Status: RESOLVED FIXED

(Directory :: LDAP C SDK, defect)

Description

[nkinder]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

The Mozilla LDAP C SDK (v5.15 or HEAD) will not build on Mac OS X 10.3.

If you checkout NSPR 4_4_1, DBM 1_61, NSS 3_9_3, SVRCORE 4_0, and LDAPCSDK 5_1_5
all in the same tree, you can sucessfully build everything up to the LDAP C SDK.
 When you try to build the LDAP C SDK, you run into the following issues:

1.) When linking libssldap.dylib, the linker will not be able to find the NSS
libraries.  This is because the library search path being supplied is incorrect.
 It is looking in dist/lib, but NSS and NSPR put their libraries in
dist/$(RELEASE_OBJDIR_NAME)/lib.

2.) When linking libprldap.dylib, the linker will not be able to find the NSPR
libraries.  This is for the same reason as #1 above.

3.) If you are trying to build the LDAP command line tools, they will fail to
link.  This is because $(RPATHFLAG_PREFIX) is not defined for OS X, so the link
command is incorrect.  On Mac OS X, there in no support for RPATH.  When a dylib
is built, you specify where executables that link with it are going to reside
with the install_name option.  This is typically a path relative to the
executable itself.

4.) If you manage to work around the above issues in #3, you will still have
troubles linking the command-line tools.  The library search paths and required
system libraries are not being passed through.

Reproducible: Always

Steps to Reproduce:

Comment 1

[nkinder]

Attachment: Proposed Fix

These changes fix the issues from my previous post.  It's basically just some
Makefile modifications for supplying the proper library paths and such.

Comment 2

[Wan-Teh Chang]

Comment on attachment 182538 [details] [diff] [review]
Proposed Fix

>Index: build.mk
...
>+# OS X doesn't have a notion of rpath.  It gets the install path from the
>+# dylib itself at link time.
>+ifneq ($(OS_ARCH), Darwin)
> LINK_EXE        = $(CC_FOR_LINK) $(ALDFLAGS) $(LDFLAGS) \
>                         $(RPATHFLAG_PREFIX)$(RPATHFLAG)$(RPATHFLAG_EXTRAS) \
>                         -o $@ $(OBJS) $(EXTRA_LIBS) $(PLATFORMLIBS)
> LINK_EXE_NOLIBSOBJS     = $(CC_FOR_LINK) $(ALDFLAGS) $(LDFLAGS) \
>                         $(RPATHFLAG_PREFIX)$(RPATHFLAG)$(RPATHFLAG_EXTRAS) -o $@
>+else
>+LINK_EXE        = $(CC_FOR_LINK) $(ALDFLAGS) $(LDFLAGS) \
>+                        -o $@ $(OBJS) $(EXTRA_LIBS) $(PLATFORMLIBS)
>+LINK_EXE_NOLIBSOBJS     = $(CC_FOR_LINK) $(ALDFLAGS) $(LDFLAGS) -o $@
>+endif # Darwin

It's easier to understand if you use ifeq instead of ifneq
and reverse the two blocks.

But it is better to simply define RPATHFLAG_PREFIX, RPATHFLAG,
and RPATHFLAG_EXTRAS to be empty for Darwin, than defining
LINK_EXE and LINK_EXE_NOLIBSOBJS in two ways.

>Index: ldap/libraries/libprldap/Makefile.in
...
> ifeq ($(OS_ARCH), Darwin)
> EXTRA_LIBS = -L$(dist_libdir) -l$(LDAP_LIBNAME)
>-EXTRA_LIBS += -L$(dist_libdir) $(DYNAMICNSPR)
>+EXTRA_LIBS += -L$(DIST)/$(RELEASE_OBJDIR_NAME)/lib $(DYNAMICNSPR)
> endif

This code shows that the LDAP C SDK already builds on Mac OS
X, and the need to use -L$(DIST)/$(RELEASE_OBJDIR_NAME)/lib
instead of $(dist_libdir) only on Darwin shows you missed
something in the build instructions.  This cannot be a Mac OS
X only build problem.

Comment 3

[Rich Megginson]

w.r.t to the last patch - it's not just a problem on Darwin, it's a problem on
every OS - every OS build needs to use -L$(DIST)/$(RELEASE_OBJDIR_NAME)/lib
$(DYNAMICNSPR) because the NSPR dynamic libs are not in $(dist_libdir).  It
seems that we have ignored this "problem" until now.  We first noticed it
building the LDAP C SDK on Solaris using the open source build instructions. 
Some platforms such as Linux create these libraries with no run time library
dependencies, and it  just works.

Comment 4

[Wan-Teh Chang]

The proper fix is probably for LDAP C SDK to instruct
NSS and NSPR's build systems where to publish their
header files and libraries.

Here are two examples in Mozilla and NSS and NSPR.  Mozilla and
NSPR use the same convention.  NSS uses a different convention
(coreconf).

1. NSS's standalone build target (nss_build_all) tells NSPR where
to publish its header files and libraries.

http://lxr.mozilla.org/security/source/security/nss/Makefile#81

See the --with-dist-prefix and --with-dist-includedir options
NSS passes to NSPR's configure script to tell it to follow
NSS coreconf's convention.

2. Mozilla's build system tells NSS where to publish its header
files and libraries.

http://lxr.mozilla.org/security/source/security/manager/Makefile.in#82

The default values of SOURCE_MD_DIR and DIST have $(OBJDIR_NAME),
which Mozilla doesn't use:
http://lxr.mozilla.org/security/source/security/coreconf/config.mk#78
http://lxr.mozilla.org/security/source/security/coreconf/source.mk#81
http://lxr.mozilla.org/security/source/security/coreconf/location.mk#62

Comment 5

[Rich Megginson]

Wan Teh, which make variable controls the location that nspr and nss use to publish their binaries?  Is it SOURCE_MD_DIR or DIST?

Comment 6

[Wan-Teh Chang]

NSS:

Programs are published in $(SOURCE_BIN_DIR), and libraries
are published in $(SOURCE_LIB_DIR).  By default,
SOURCE_BIN_DIR = $(SOURCE_MD_DIR)/bin
SOURCE_LIB_DIR = $(SOURCE_MD_DIR)/lib

So if you also use "bin" and "lib" subdirectories under
the binary publication location, you just need to override
SOURCE_MD_DIR.  Otherwise you need to override SOURCE_BIN_DIR
and SOURCE_LIB_DIR.

You may need to override DIST, too.

NSPR:

run "mozilla/nsprpub/configure --help" and experiment with
the various --with-dist-xxx configure options.

Comment 7

[Rich Megginson]

I was hoping for something that would be "passed through" to NSPR when you do the combined build 
cd mozilla/security/nss ; make nss_build_all
when you do that, nss passes the compiler flags to nspr and makes it first.

Comment 8

[Rich Megginson]

Nathan, can you try a build with the latest code from HEAD?

Comment 9

[nkinder]

Attachment: Proposed Fix

These changes were required for the build from HEAD to work on OS X 10.3.9.  I had to unset RPATHFLAG and RPATHFLAG_PREFIX, use g++ to link the command-line tools, and link the command-line tools with libiconv.dylib.

Comment 10

[Rich Megginson]

Checking in build.mk;
/cvsroot/mozilla/directory/c-sdk/build.mk,v  <--  build.mk
new revision: 5.30; previous revision: 5.29
done
Checking in ldap/clients/tools/Makefile.in;
/cvsroot/mozilla/directory/c-sdk/ldap/clients/tools/Makefile.in,v  <--  Makefile.in
new revision: 5.13; previous revision: 5.12
done