User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
This only happens with libprldap and libssldap. It uses -L$(dist_libdir) to
find the NSPR libs but they are actually in dist/PLATFORM/lib. I've changed it
to use -L$(DIST)/$(RELEASE_OBJDIR_NAME)/lib and it works, but I don't know if
that is the most appropriate macro to use.
Created attachment 181901 [details]
Diffs for fix
Uses $(DIST)/$(RELEASE_OBJDIR_NAME)/lib to find the NSPR shared libs.
Why is this only a problem on Solaris?
I don't know. I suspect that it will be a problem on other platforms that
require shared libraries to link against when building a shared libraries.
Another way to do it would be to omit the NSPR libraries when linking
libprldap.so. Are they really required? It seems that linking libssldap.so
does not require the NSS libraries, only the NSPR libraries. I'm not sure why.
A little more digging reveals that Solaris builds just fine without building in
any dependencies to the NSPR shared libraries.
On Linux, libprldap.so and libssldap.so are built with no run time dependencies.
Other components do build in dependencies. For example, NSS builds in run time
dependencies to NSPR.
It seems like the right thing to do is to build in run time dependencies to NSPR
and NSS on all platforms, to at least make it consistent.
I'd like to go ahead and check in the fix listed in the diffs, to at least
enable building on Solaris using the configure build method.
Checking in mozilla/directory/c-sdk/ldap/libraries/libprldap/Makefile.in;
new revision: 5.11; previous revision: 5.10
Checking in mozilla/directory/c-sdk/ldap/libraries/libssldap/Makefile.in;
new revision: 5.9; previous revision: 5.8