Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 227452 - Solaris build: Need to add other libs for autotool build
Summary: Solaris build: Need to add other libs for autotool build
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.0.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: FDS1.1.0
TreeView+ depends on / blocked
 
Reported: 2007-02-05 23:40 UTC by Rich Megginson
Modified: 2015-12-07 16:30 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:30:27 UTC


Attachments (Terms of Use)
diffs (deleted)
2007-02-05 23:45 UTC, Rich Megginson
no flags Details | Diff
m4 fix for libdir (deleted)
2007-02-06 00:00 UTC, Rich Megginson
no flags Details | Diff

Description Rich Megginson 2007-02-05 23:40:29 UTC
Various exes/libs are missing -lsocket, -lnsl, and -ldl

Comment 1 Rich Megginson 2007-02-05 23:45:35 UTC
Created attachment 147419 [details]
diffs

Comment 2 Rich Megginson 2007-02-06 00:00:30 UTC
Created attachment 147420 [details]
m4 fix for libdir

Addendum: The method to determine libdir is broken on Solaris because
--libs-only-L returns two paths and the regexp to return just the first one was
missing a "." before the "*".

Comment 3 Noriko Hosoi 2007-02-06 02:47:14 UTC
Looks good.

Comment 4 Nathan Kinder 2007-02-06 16:31:08 UTC
The changes look good, but there is one issue with using the AC_CHECK_LIB macro.  

I have not found a way to tell AC_CHCEK_LIB a library search path other than
setting LD_LIBRARY_PATH.  This means that our test for db_create will use a
system libdb-4.2 even if you specify a different location for libdb with the
"--with-db" configure option.  You can see exactly what configure is doing when
it tests for db_create in the config.log.  Do we really need to check for
db_create in db.m4?

Comment 5 Rich Megginson 2007-02-06 16:38:24 UTC
(In reply to comment #4)
> I have not found a way to tell AC_CHCEK_LIB a library search path other than
> setting LD_LIBRARY_PATH.  This means that our test for db_create will use a
> system libdb-4.2 even if you specify a different location for libdb with the
> "--with-db" configure option.  You can see exactly what configure is doing when
> it tests for db_create in the config.log.

There are ways to do it e.g. set LDFLAGS to -L/path/to/libdir before the
AC_CHECK_LIB macro.

> Do we really need to check for db_create in db.m4?

I'd rather have the build blow up during configure than later.

Comment 6 Rich Megginson 2007-02-06 16:40:19 UTC
Reviewed by: nhosoi, nkinder (Thanks!)
Files: see diff
Branch: HEAD
Fix Description: The AC_CHECK_LIB test for db_create needs -lnsl because libdb
links with it on Solaris.  Other executables require -lnsl, -lsocket, and -ldl.
 The strategy is to put these in the platform specific section in configure.ac
so they can be exported to the Makefile.  Then we can just use the macros
directly in Makefile.  On platforms where these are not required, they will
evaluate to empty.
There was a bug in the regexp that derived the libdir from pkg-config in several
m4 files.  We needed to use .* instead of just *.  pkg-config --libs-only-L
returns multiple paths on Solaris but not on linux.
Platforms tested: Solaris 9
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none 

Checking in aclocal.m4;
/cvs/dirsec/ldapserver/aclocal.m4,v  <--  aclocal.m4
new revision: 1.12; previous revision: 1.11
done
Checking in Makefile.am;
/cvs/dirsec/ldapserver/Makefile.am,v  <--  Makefile.am
new revision: 1.20; previous revision: 1.19
done
Checking in Makefile.in;
/cvs/dirsec/ldapserver/Makefile.in,v  <--  Makefile.in
new revision: 1.22; previous revision: 1.21
done
Checking in config.guess;
/cvs/dirsec/ldapserver/config.guess,v  <--  config.guess
new revision: 1.6; previous revision: 1.5
done
Checking in config.sub;
/cvs/dirsec/ldapserver/config.sub,v  <--  config.sub
new revision: 1.6; previous revision: 1.5
done
Checking in configure;
/cvs/dirsec/ldapserver/configure,v  <--  configure
new revision: 1.21; previous revision: 1.20
done
Checking in configure.ac;
/cvs/dirsec/ldapserver/configure.ac,v  <--  configure.ac
new revision: 1.15; previous revision: 1.14
done
Checking in ltmain.sh;
/cvs/dirsec/ldapserver/ltmain.sh,v  <--  ltmain.sh
new revision: 1.5; previous revision: 1.4
done
Checking in m4/nspr.m4;
/cvs/dirsec/ldapserver/m4/nspr.m4,v  <--  nspr.m4
new revision: 1.5; previous revision: 1.4
done
Checking in m4/nss.m4;
/cvs/dirsec/ldapserver/m4/nss.m4,v  <--  nss.m4
new revision: 1.5; previous revision: 1.4
done
Checking in m4/mozldap.m4;
/cvs/dirsec/ldapserver/m4/mozldap.m4,v  <--  mozldap.m4
new revision: 1.8; previous revision: 1.7
done
Checking in m4/db.m4;
/cvs/dirsec/ldapserver/m4/db.m4,v  <--  db.m4
new revision: 1.5; previous revision: 1.4
done


Comment 7 Rich Megginson 2007-02-06 17:30:21 UTC
For finding libs in non-default places, I think there are two options:
1) Just skip searching for the library if the libpath was explicitly given to
configure. e.g. if the user did configure --with-db=/path/to/db, just assume the
user knows what he/she is doing, and skip the AC_CHECK_LIB test.
2) Hack LDFLAGS e.g. something like this:
save_LDFLAGS="$LDFLAGS"
LDFLAGS="$save_LDFLAGS -L/path/to/dblibdir"
AC_CHECK_LIB([db-$dbver], [db_create],.....)
LDFLAGS="$save_LDFLAGS"

I've used this with other similar problems in the past e.g. with mozldap and
sasl.m4.

Comment 8 Nathan Kinder 2007-12-20 21:26:41 UTC
The current Solaris builds are building fine and locating all of the necessary
libraries at configure time.  The acceptance tests are also proving the the
libraries are being found properly at runtime, otherwise we'd see crashes and
missing symbols.

I also verified that ns-slapd is indeed linked with libnsl, libsocket, and libdl.

Marking as VERIFIED.


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