[Date Prev][Date Next]
Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
> Hallvard B Furuseth wrote:
>> firstname.lastname@example.org 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/