Bug 204563 - Solaris build problem
Solaris build problem
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
sparc Other
medium Severity medium
: ---
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
Depends On:
Blocks: 152373 240316
  Show dependency treegraph
Reported: 2006-08-29 20:30 EDT by Noriko Hosoi
Modified: 2015-12-07 11:36 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-07 11:36:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
cvs commit message (628 bytes, text/plain)
2006-08-29 22:21 EDT, Noriko Hosoi
no flags Details

  None (edit)
Description Noriko Hosoi 2006-08-29 20:30:53 EDT
Description of problem:
After picking up the new LDAP C SDK (v5.17-sun-merge), Solaris build
(libslapd.so) has started
failing due to undefined symbols
Undefined                       first referenced
symbol                             in file
ld: fatal: Symbol referencing errors. No output written to
gmake[4]: ***
[../../../built/release/SunOS5.9_64_DBG.OBJ/bin/slapd/server/libslapd.so] Error 1
gmake[4]: Leaving directory
Comment 1 Noriko Hosoi 2006-08-29 20:32:50 EDT
Solaris build has started failing since we switched to v5.17-sun-merge.  The
reason is the new LDAP C SDK contains the sasl symbols.  By default, the
undefined symbols are allowed in the shared library.  But libmakefile is
explicitly setting '-z defs' to the ld command line (see the comments in
libmakefile below).  That kind of checking is not done on the other platforms. 
How do we want to fix this?  1) Adding "-lsasl2" to build libslapd.so?  Or 2)
dropping "-z defs"?

    $ nm
/share/builds/components/ldapsdk50/v5.17/SunOS5.9_64_DBG.OBJ/lib/libldap50.so |
grep "\<sasl_"

    $ nm
| grep "\<sasl_"
    [1944]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_client_init
    [1782]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_client_new
    [1743]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_client_start
    [1949]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_client_step
    [1880]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_decode
    [1647]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_dispose
    [1861]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_encode
    [1832]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_errdetail
    [1824]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_getprop
    [1760]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_set_alloc
    [1710]  |             0|           0|FUNC |GLOB |0    |UNDEF  |sasl_setprop

# for Solaris, our most common unix build platform, we check for undefined
# symbols at link time so we don't catch them at run time.  To do this, we
# set the -z defs flag.  We also have to add explicitly link with the C and
# C++ runtime libraries (e.g., -lc) because, even though ld and CC link
# with them implicitly, -z defs will throw errors if we do not link with
# them explicitly.
ifeq ($(ARCH), SOLARIS)
LINK_DLL += -z defs

>From 'man ld'
     -z defs | nodefs
           The -z defs option forces a fatal error if  any  unde-
           fined  symbols  remain at the end of the link. This is
           the default when an executable is built, but for  his-
           toric  reasons  is  not  the  default  when building a
           shared object. Use of the -z  defs  option  is  recom-
           mended,  as it assures the object being built is self-
           contained, that is, that all its  symbolic  references
           are  resolved  internally or to the object's immediate

           The -z nodefs option  allows  undefined  symbols.  For
           historic  reasons,  this  is the default when a shared
           object is  built.  When  used  with  executables,  the
           behavior  of  references  to such undefined symbols is
           unspecified. Use of the -z nodefs option is not recom-
Comment 2 Noriko Hosoi 2006-08-29 21:38:38 EDT
We have to give up "-z defs" for libback-ldbm.so, too.

Index: Makefile
RCS file: /cvs/dirsec/ldapserver/ldap/servers/slapd/back-ldbm/Makefile,v
retrieving revision 1.7
diff -t -w -U10 -r1.7 Makefile
--- Makefile    19 Apr 2005 22:07:37 -0000      1.7
+++ Makefile    30 Aug 2006 01:38:13 -0000
@@ -127,21 +127,22 @@
 ifeq ($(ARCH), SOLARIS)
         $(LDAPSDK_DEP) \
         $(LDAP_LIBLDIF_DEP) \
         $(LDAP_LIBLDIF) \
         $(LDAP_LIBAVL) \
         $(DLL_EXTRA_LIBS) -lc
-LINK_DLL += -z defs
+# All the dependent libraries may not be linked with. (e.g., Cyrus SASL)
+# LINK_DLL += -z defs
Comment 3 Noriko Hosoi 2006-08-29 22:21:16 EDT
Created attachment 135180 [details]
cvs commit message

As discussed in the Directory Server meeting, checked in the makefiles into
Comment 4 Noriko Hosoi 2007-11-29 13:39:53 EST
Verified build: /share/dev4/ds/ds80/logs/20071129.1/mars_Solaris9

libslapd.so is successfully built:
/usr/ccs/bin/ld -64 -G -h libslapd.so.0 -o .libs/libslapd.so.0.0.0 
ldap/servers/slapd/.libs/libslapd_la-add.o ...  -L/usr/lib/sparcv9 -lssldap60
-lprldap60 -lldap60 -lldif60 -lsasl2 -lsvrcore -lssl3 -lnss3 -lsoftokn3 -lplc4
-lplds4 -lnspr4 -lc
(cd .libs && rm -f libslapd.so.0 && ln -s libslapd.so.0.0.0 libslapd.so.0)
(cd .libs && rm -f libslapd.so && ln -s libslapd.so.0.0.0 libslapd.so)
creating libslapd.la

I.e., verified.

Note You need to log in before you can comment on or make changes to this bug.