mills@cc.umanitoba.ca wrote:
Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29)
The usual procedure is to run `configure' and `make' in the install tree as an ordinary user, and then to run `make install' there as root. This install procedure writes to the install tree as root. In some cases, it actually relinks a shared library as root. We build on one server and install on another, where the install tree is mounted read-only. These errors prevent installation in this case.
Really, it shouldn't be doing relinking at that point, when running as root. Perhaps it could do it earlier, during the compile step. I had to do a `make install' as root in libraries/liblber on build server and then modify the Makefiles in libraries/libldap and libraries/libldap_r to link with the installed library, in order to avoid the relink on the install server. This worked, but is not a good solution.
Agreed, it should not be relinking, ever, but that's libtool. I've submitted patches to libtool to correct this a number of times over the past several years but the problem remains, and it's our policy to avoid using customized OpenLDAP-specific versions of the GNU tools so we no longer provide patched versions of libtool in our CVS.
In the meantime, there's no reason for this to be affecting your source tree. You can always build using an object tree separate from the source tree. And you can always use "make install DESTDIR=/tmp/foo" on the build system to create an alternate hierarchy that can then be copied to any other machine.
Since there is no fundamental bug in OpenLDAP here, this ITS will be closed.