Re: libtool compilation failures (ITS#795)

[Kurt@OpenLDAP.org]

This sounds like a problem with a particular repackaging of
OpenLDAP and not with OpenLDAP as provided by the project.  If a
re-packager mucks with the build environment, they can easily
much things up.  The re-packager "owns" any issues resulting
from such changes.

As far as OpenLDAP supporting multiple versions of libtool, this
is not terribly feasible and makes little sense.  libtool is
designed as an "embedded" tool.  We only need to be compatible
with the version of libtool which we "embed" in our build system.
If someone mucks with the build system, they can easily muck it
up.

As far as upgrading to libtool 1.3.5, that will happen in due
course.  Likely not for 2.0, maybe for 2.1, more likely 2.2.


At 04:37 AM 10/1/00 +0000, jlittle@open-it.org wrote5:
>Full_Name: Joe Little
>Version: 2.0.4
>OS: Redhat Linux 7.0
>URL: 
>Submission from: (NULL) (64.161.126.156)
>
>
>Although a direct compile (./configuure after untaring) does correctly use
>build/ltmain.sh in the source tree to create /libtool in the main directory,
>an RPM build (which calls /usr/bin/libtoolize) generates a libtool from outside
>the openldap build tree. In the case of OpenLdap 2.0.4, the result is a build
>using either libtool 1.3.4 (rh6.2) or 1.3.5 (rh70). Both version's have an
>ltmain.sh which do not have
>
>  --only-shared)
>    build_libtool_libs=yes
>    build_old_libs=no
>    ;;
>
>  --only-static)
>    build_libtool_libs=no
>    build_old_libs=yes
>    ;;
>
>in its definition. The slapd/backend-ldbm makefile calls libtool with
>--only-static.
>On Redhat 6.2/7.0 systems (and likely any RPM-based system with libtool >
>1.3.3),
>an RPM build fails.
>
>This is either an issue specific to OpenLDAP's build system, or possibly to
>incorrect
>new configuration in libtool 1.3.4/1.3.5. In any case, it maybe wise for
>OpenLDAP to 
>correctly handle all libtool versions or maybe use 1.3.5 out of the box.