[Date Prev][Date Next]
Re: libtool compilation failures (ITS#795)
I do question if this version is self-consistent within openldap
2.0.x.. For instance, openldap versions 1.2.x still compile correctly
which the same differences in libtool. I am wondering if how it has been
used in 2.0.x is open to mis-predicted behavior. I'll wage this as well in
the RPM cycles, but an "error" in say libtool 1.3.3, if such existed, that
is "self-consistent" in your build, is an error nonetheless, and can
affect your package on a percentage of your platforms..
On Mon, 2 Oct 2000, Kurt D. Zeilenga wrote:
> At 04:27 PM 10/2/00 +0000, firstname.lastname@example.org wrote:
> >I could be wrong in this and overstating the case, but its no end of
> >frustration, and I still consider it an open issue.
> The application developer has already 'libtoolized' the application
> and has ensured that the build environment is self consistent.
> If another developer wants to update the version of libtool used,
> then that application developer needs to ensure the resultant
> build environment is self consistent.
> If the RPM system wants to update the version of libtool used,
> than the RPM system needs to ensure the resultant build systems
> is self consistent. I do not see how it possible to automate
> such an update.
> This isn't really an OpenLDAP issue, it's an RPM issue.