Re: libtool compilation failures (ITS#795)

[jlittle@open-it.org]

I agree about mucking with the build system.

To recap:

openldap 2.0.4 builds normally on a system with or without the libtool
package being installed. However, if libtoolize is called previous to
running configure (which rpm and other programs do), the purported purpose
is to check the /build tree and generate libtool before configure (whereas
configure will attempt to do it itself if libtoolize has not been
run). The problem stems from the fact that libtoolize creates a different
libtool than that packaged with openldap 2.0.4 (libtool 1.3.3) whereas
openldap 1.2.x creates a one at harmony with system definitions. the
openldap 2.0.4 version conflicts with the system libtool definitions in
the arguments it accepts. 

Specifically, the backend-ldbm makes use of a call, --only-static, that is
not a function in libtool > 1.3.3 and likely not before that version. It
may have been orphaned. This is the only part of openldap that calls this
flag (it should likely call -static instead). 

I have not tracked down earlier versions of libtool to see how long the
"--only-static" flag worked. However, the success of all openldap 1.2.x
versions on all previously included libtools lead me to first raise the
issue with OpenLDAP 2.0.x inclusion of 1.3.3.. I felt it the primary
suspect. Again, this is where I may indeed be wrong. I'm only asking for
it to be checked for consistency by your team since it was suspect.

	-Joe


On Mon, 2 Oct 2000, Kurt D. Zeilenga wrote:

> At 06:21 PM 10/2/00 +0000, jlittle@open-it.org wrote:
> >I do question if this version is self-consistent within openldap
> >2.0.x..
> 
> Originally you said it worked "correctly" as shipped, but failed
> when you forced an libtool update.  I said "don't do that".
> 
> If you now say 2.0.4 fails as shipped, that's a different issue.
> Describe how it fails and we'll work with you on resolving the
> problem.
> 
> >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..
> 
> Our build system on the other hand might workaround take this mythical
> error... and by "updating" the component, you are actually breaking
> things, not fixing things.  It is terribly unwise to arbitrarily
> update components of the system.
> 
> Now, we are looking updating to libtool to resolve some reported
> issues (such as AIX/HP/Darwin support) and will take reasonable
> care in that the changes continue to work correctly "out-of-the-box".
> As before, if someone mucks with the build system, they run the
> risk of mucking things up...  there is no escaping this fact.
> 
> Kurt
>