Re: (ITS#3982) libldap compile settings

[nbk@sitadelle.com]

Kurt D. Zeilenga wrote:

> 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.

I see. If OpenLDAP binaries cannot easily be built statically, I have
little chance to build FreeRADIUS binaries statically (at least with
LDAP support enabled). Thanks for letting me know that.

> 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.

We both agree that it won't work. My opinion is this is a corner case,
and I don't worry too much about it. If the user deliberately builds
on the same host OpenLDAP and the client application with different
compiler or binutils, he has to be prepared for some difficulties.

> 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.

I understand your concerns about the options accepted by one build
tool chain and not another. However, it'd still possible to have
the openldap_config script to return just the pathnames of the
local installation, with nothing preceding them.

$ openldap_config --includedir
/path/to/include
$ openldap_config --libdir
/path/to/lib

I note this will not provide the libldap dependancies, but your
previous answers make me think I should give up on that. However,
I still think it'd be useful to have at least the pathnames where
the libldap and its headers are installed on the local system.

>> 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.

This would be true is FreeRADIUS was also using libsasl, but this is
not the case. The -lsasl is there only for a (desperate?) attempt to
please libldap dependancies. This turns out to be a bug because at
some point newer libldap didn't depend upon -lsasl anymore but -lsasl2
instead.

If I'm not mistaken, the best we can do to support LDAP in FreeRADIUS
is to link with -lldap only. If the environment offers a dynamic
library, everything should be fine. If that's not the case (static
libldap only) linkage will fail and the user will have to provide the
missing dependancies in the variable LDFLAGS.

-- 
Nicolas Baradakis