Re: (ITS#5929) 'make test' uses installed libldap_r/liblber

[hyc@symas.com]

hyc@symas.com wrote:
> Hallvard B Furuseth wrote:
>> hyc@symas.com writes:
>>>> Seems to me we need to reinstate those commands.
>>> Fixed now in HEAD
>> Didn't help.  But I'm not sure it was necessary anyway - after all it
>> did find the libraries when I did not set LDPATH, even though there
>> were no symlinks.  Something is being quite magical.
>>
> Eh. I'd forgotten. The libtool script generates a wrapper script for each
> binary that sets LD_LIBRARY_PATH already. So really we should remove the
> LD_LIBRARY_PATH export from scripts/defines.sh.
>
> And that means your problem is a libtool problem.

I played with this a bit more. The situation is this:

The ELF linker doesn't store the absolute pathnames of dependent dynamic 
libraries, so it relies entirely on compiled-in runpaths and environment runpaths.

Our default invocations of libtool never supply a runpath.

Since you're adding one explicitly to your build, without any other settings, 
your runpath is the only one in effect. Since you're setting both -L and 
-rpath, your binaries will be linked and executed against your installed libs, 
regardless of what the libtool wrapper script does.

If you want this to work you'll have to provide both the build directory and 
your installed directory in your -rpath.

The symlinks would then help a little, because you only need to set one build 
rpath instead of 3. Go ahead and restore the build rules in your source tree 
to set the symlinks if you want them. At the moment it looks like they're not 
generally useful, and I'm tired of committing/reverting, so I'm not touching 
those files any more today.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/