[Date Prev][Date Next]
Re: libtool compilation failures (ITS#795)
At 07:10 PM 10/2/00 +0000, owner-openldap-bugs@OpenLDAP.org wrote:
>I agree about mucking with the build system.
Then don't do that.
>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
No, purpose of running libtoolize is to muck with the build system.
Running libtoolize will report:
Putting files in AC_CONFIG_AUX_DIR, `build'.
libtoolize: `config.guess' exists: use `--force' to overwrite
libtoolize: `config.sub' exists: use `--force' to overwrite
libtoolize: `ltconfig' exists: use `--force' to overwrite
libtoolize: `ltmain.sh' exists: use `--force' to overwrite
Don't do that.
>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.
In both cases, running libtoolize --force replaces the libtool version
used by the package. Doing such can break things. Don't do that.
>the openldap 2.0.4 version conflicts with the system libtool definitions in
>the arguments it accepts.
So, don't do that.
>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.
And when the application developers choose to update libtool they
will have to deal with this as well as other differences between
libtool versions. This is why arbitrarily updating build system
components is not wise. If you choose to libtoolize --force on
your own, then you'll have to deal with it. If you some re-packaging
that does this, complain to them with it doesn't work.
> It may have been orphaned.
Yes... things change between tool releases. It is impossible to
guess at what those changes might be. This is why ship a complete
>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.
That's irrelevant. It only matters that it is supported in the
"out-of-box" build environment. Newer libtool versions obviously
use newer mechanisms requiring changes to the build environment.
>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..
2.0 supports dynamically linkable modules and hence uses additional
features of libtool. This implies that 2.0 will be more prone to
subtle differences between libtool versions.