Re: (ITS#3982) libldap compile settings

[Kurt@OpenLDAP.org]

At 07:55 AM 9/4/2005, nbk@sitadelle.com wrote:
>Kurt D. Zeilenga wrote:
>
>> Generally, we detect (or env is provided) for dynamic linking.  For
>> instance, we likely only know that -lsasl links in SASL using some
>> provided -L's (and/or whatever), but we don't know what libraries
>> -lsasl might dynamically link in.  If, like you, the user wants to
>> statically link in -lldap, then -lsasl and its dependencies will
>> also need to be statically linked in.  Using -lsasl and those -L's
>> (and/or whatever) simply won't cut it.
>
>Reading your answers, my impression is static linkage for OpenLDAP
>binaries is broken, too. If that's the case, there's no way I can fix
>static linkage for LDAP support in FreeRADIUS. I wonder what happens
>when you run ./configure --disable-shared in the OpenLDAP source tree.

Works for me.   But I note that --disable-shared only disables
building of OpenLDAP shared libraries, it doesn't disable use of
other shared libraries by OpenLDAP tools.  So, -lsasl brings
in what's needed dynamically.

dntest:
        libsasl2.so.2 => /usr/pkg/lib/libsasl2.so.2 (0x2808e000)
        libssl.so.3 => /usr/lib/libssl.so.3 (0x280a1000)
        libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x280d1000)
        libfetch.so.3 => /usr/lib/libfetch.so.3 (0x281cf000)
        libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x281dc000)
        libc.so.4 => /usr/lib/libc.so.4 (0x281de000)

Now, if the build environment only offered a static -lsasl2,
its quite likely that our configure would not detect all of
possible dependencies of it.

This implies that a program statically linking in -lldap using
the same build environment that was used to link ldapsearch
can easily fail because they need to statically link in -lsasl
and its dependencies.  Our build environment isn't designed
for that.  It's designed to dynamically link in -lsasl.

>> Also, there is no guarantee (*) that the client developer is using
>> the same compiler tool chain as was used to build ldap libraries.
>> That can cause all kinds of problems.
>> (* given that we use a custom libtool, one can argue its guaranteed
>> that the -lldap installer is using a different build
>> environment/tool chain...)
>
>Different versions of libtool would be an issue if the client
>developper try to use the file libldap.la. However, you usually don't
>install this file in /usr/lib. (but the file libldap.a instead)

You seemed to focused in on a comment and ignored the
basic point.

Duplicating a few environment variables is an incomplete
solution.  The -lldap build environment was suited to a
particular build tool chain and simply may not work with
another build tool chain. 

For instance, the libraries may have been built with system
compiler (say something other than gcc), but the user of library
may be using some other compiler (say gcc) (or vice versa).
One cannot assume the flags one work for the other.

(It's also noted that LIBS and stuff may not even be needed by
other programs, they may have been provided for slapd(8) building.
-lldap may have no actual dependency on LIBS.)

>> I note that your script assumes that the complier tool chain accepts
>> -I/..., that's actually a bad assumption.  There are certainly
>> compiler tool chains for POSIX -based (or -like) systems which don't
>> take -I's.  My point here not to ding this particular assumption,
>> but to ding the more general assumption that client developer has a
>> comparable environment/tool chain to that used by the -lldap
>> installer.
>
>The goal here is to save the options used to build OpenLDAP binaries
>on the *local* system.

But what you are saving are options used in the installer's
build environment, for use with the installer's build tool
chain.  To be useful, one also has to save what that build
tool chain is.

>If the user builds on his system different
>libraries with different compiler/binutils, and if it doesn't work,
>then I think he deserves what he gets.

How does the user know which compiler/binutils to use?
Your script seems not to provide that.

>> Personally, I have never found these scripts to be particularly
>> useful...
>
>As a developper of the FreeRADIUS project, my experience is we have
>less build-related problems with MySQL and PostgreSQL (which provides
>scripts mysql_config and pg_config) than OpenLDAP.
>
>Here's a concrete example of the problems from the libldap dependancies:
>http://bugs.freeradius.org/show_bug.cgi?id=73

This has nothing to do with finding dependencies, which your
script is intended to help solve, but with symbol clashes.
Your script does nothing to resolve the problem where a
program (directly or indirectly) requires two libraries
which export symbols that clash.

I think its a mistake to confuse solutions for dealing with
symbol clashes in correctly found libraries with solutions
for correctly finding dependent libraries.

Kurt