Custom prefix --with-serf and --with-zlib are handled wrong

[Alexandr Miloslavskiy <al...@syntevo.com>]

At least on Linux, SVN build scripts handle custom-prefix dependencies
--with-serf and --with-zlib incorrectly.

For example, for --with-serf, the following happens

1) serf.pc is found at provided prefix, which gives:
    -lserf-1 -L/path/to/serf/prefix
2) This is given to libtool, which is the core of SVN's build system
3) libtool does NOT record RPATH/RUNPATH for dependencies like `-l*`.
    Some other dependencies, like --with-apr, also use libtool, and
    libtool handles these correctly. The problem is only about `-l*`.
4) The built binary does not know where to find `libserf-1.so` and
    fails to start. This can of course be helped with `LD_LIBRARY_PATH`,
    but it's not convenient to do so. See previous discussions [3][4].

In a recent patch [1] I tried to give additional `-R` to libtool to
convince it to record proper RPATH/RUNPATH. This fixes issues when
building, but still results in incorrect binary. This time, because
libtool has option `link_all_deplibs` enabled (by having the value of
`unknown` which is different from `no`), which causes it to link
dependencies-of-dependencies recursively into svn binaries. While doing
so, it forgets to pick up -R and the result is that the final binary
again doesn't know where to find serf. This is an oversight in libtool.

To me, it's pretty weird that `link_all_deplibs` is enabled at all,
because Linux loader doesn't need any help when handling
dependencies-of-dependencies. So `svn` binary doesn't need to have
`libserf-1` dependency linked explicitly only because one of its
dependencies has it. I've read some discussion [2] in Debian where they
disabled the option, but it seems that option is necessary in some more
exotic cases such as cross-compilation. I'm not experienced enough to
say whether it should be kept.

As for --with-zlib, the problem is similar, but Linux seems to have
zlib preinstalled, so built svn will "secretly" load the wrong zlib
(that is, system installed instead of provided via --with-zlib), so the
problem is less visible.

So far I have spent a whole day digging through libtool internals and
didn't find good approaches to solve the problem. What could be done is
to apply my patch from [1] and disable `link_all_deplibs` on Linux.

I am giving up, I guess. Our build system just patches out RPATH in
produced binaries (to make them portable) anyway. I hoped to fix the
problem in general, but libtool misbehaves, and it seems that it's also
dead already, so there are no hopes for a fix.

[1] 
https://mail-archives.apache.org/mod_mbox/subversion-dev/202107.mbox/%3Ca89d070e-2586-d8ef-9c16-b710dbc7deb0%40syntevo.com%3E
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297726
[3] https://stackoverflow.com/questions/28663316
[4] https://groups.google.com/g/subversion_users/c/CkbGGwFi6-0