RE: [Issue 1518] - make install fails ...

[Kim Lester <ki...@dfusion.com.au>]

As it happens I have exactly the same problem today.
I came across it several months ago and now have to address it.
If memory serves the following occurs.

commands:

configure --prefix=ultimate_install_path
...
make DESTDIR=temporary_root install

What happens (at least under solaris 8) is that libtool
is being 'too smart'.
It says "ahh I see you are installing somwhere else,
  I'll relink all the .so's so that the paths are correct"

Also from memory the install script tries to install "a bunch of .so's"
in the ultimate_install_path rather than into the temporary_root.
I think libsvn_client-1.so.0 was one of these and hence the
source of the complaint when svnversion dies trying to load libsvn_client.so.

The problems do NOT occur (in the same way) when installing as root because
root permits the install script to put these libs in the ultimate_install_path

The bottom line is that the install process does not appear to obey the DESTDIR completely
and that libtool appears to cause trouble as well.

There might also be a minor issue in that part of the install process
is to run svnversion which fails as non of the libs are in the ultimate_install_path
(I expect an explicit LD_LIBRARY_PATH=...:temporary_root/ultimate_install_path  might fix
this).

I note that the packages/rpm patches fiddle with DESTDIR, they may have been addressing
part of the problem.

This really is a problem for people who, for many valid reasons,
can't directly install subversion in its target location.

Some assistance on the correct way to address this would be appreciated.
I would prefer not to become a libtool or autoconf expert :-)

regards
	Kim



> -----Original Message-----
> From: Anthony Baxter [mailto:anthony@interlink.com.au]
> Sent: Monday, September 15, 2003 10:41 PM
> To: Michael Wood
> Cc: users@subversion.tigris.org
> Subject: Re: [Issue 1518] - make install fails with ld.so failure on
> libsvn_client-1.so.0 
> 
> 
> 
> >>> Michael Wood wrote
> > As I asked in my reply to your issue about the prefix thing:
> > 
> > Did you try "make DESTDIR=/path/to/install/to install"?
> 
> Sorry, I thought I'd responded to this - initially this didn't work, but
> I just tried it again and it seems to work. I'm not sure if this is because
> I'm using the 'experimental libtool' this time (unfortunately the box I'm 
> compiling on is an Ultra5, which doesn't encourage lots of re-compiling)
> -- 
> Anthony Baxter     <an...@interlink.com.au>   
> It's never too late to have a happy childhood.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [Issue 1518] - make install fails ...

[Philip Martin <ph...@codematters.co.uk>]

"Kim Lester" <ki...@dfusion.com.au> writes:

> configure --prefix=ultimate_install_path
> ...
> make DESTDIR=temporary_root install
>
> What happens (at least under solaris 8) is that libtool
> is being 'too smart'.
> It says "ahh I see you are installing somwhere else,
>   I'll relink all the .so's so that the paths are correct"

If libtool doesn't work on Solaris then you should send bug reports to
libtool.  If libtool really isn't working it may not be possible for
Subversion to work around it.

On Linux I tried

  configure --prefix=/usr/local/subversion
  make
  make install DESTDIR=foo
  make swig-py
  make install-swig-py DESTDIR=foo

and it appears to work, the Subversion libraries and binaries and the
Apache modules are installed under foo, nothing gets installed in
prefix.  I do get some warnings (about uninstalled libraries) when
installing binaries, but no errors.

> Also from memory the install script tries to install "a bunch of .so's"
> in the ultimate_install_path rather than into the temporary_root.
> I think libsvn_client-1.so.0 was one of these and hence the
> source of the complaint when svnversion dies trying to load libsvn_client.so.

That doesn't happen when I try it, and even if it did it would not
cause svnversion to fail.  When svnversion is executed it runs from
the build directory using the libraries in the build tree, whether (or
where) Subversion is installed doesn't matter.  I'd be surprised if it
doesn't work as the regression tests rely on running binaries from the
build directory.

> The problems do NOT occur (in the same way) when installing as root because
> root permits the install script to put these libs in the ultimate_install_path
>
> The bottom line is that the install process does not appear to obey
> the DESTDIR completely and that libtool appears to cause trouble as
> well.

The "bottom line" as far as I am concerned is that it works when I try
it.

> There might also be a minor issue in that part of the install
> process is to run svnversion which fails as non of the libs are in
> the ultimate_install_path (I expect an explicit
> LD_LIBRARY_PATH=...:temporary_root/ultimate_install_path might fix
> this).

That should not be needed.

> I note that the packages/rpm patches fiddle with DESTDIR, they may
> have been addressing part of the problem.

My guess is that those rpm patches are out of date and no longer
needed, but I don't build rpms so I can't be sure.

> This really is a problem for people who, for many valid reasons,
> can't directly install subversion in its target location.
>
> Some assistance on the correct way to address this would be appreciated.

Don't report errors "from memory".  Run the commands and report the
exact errors.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org