It seems that the problem has been there for years, see for example:
https://stackoverflow.com/questions/28663316
https://groups.google.com/g/subversion_users/c/CkbGGwFi6-0
I'm a committer in SVN, but I'm not very experienced with Linux and would
rather have this patch reviewed, thanks!
[[[
Fix libsvn_ra_serf build with external serf
Since `serf` transitioned to `SCons` build system in 2011, it no longer
generates `.la` files. At the same time, `libtool` only adds `-rpath`
when dependency is given as `.la`. As a result, if serf is not installed
in default path, `libsvn_ra_serf-1.so` doesn't know where to find its
`libserf-1` dependency.
When OS's `ld` linker defaults to `RPATH`, build still works, probably
because one of other dependencies introduce path to `serf`. On newer
systems where `ld` defaults to `RUNPATH`, build fails.
Fix this by inserting correct `-rpath` to find `libserf-1`.
* build/ac-macros/serf.m4
Workaround for libtool to append correct -rpath for serf dependency
]]]
Index: build/ac-macros/serf.m4
===================================================================
--- build/ac-macros/serf.m4 (revision 1891835)
+++ build/ac-macros/serf.m4 (working copy)
@@ -170,6 +170,14 @@
serf_found=yes
SVN_SERF_INCLUDES=[`$PKG_CONFIG $serf_pc_arg --cflags-only-I`]
SVN_SERF_LIBS=[`$PKG_CONFIG $serf_pc_arg --libs-only-l`]
+ if test -n "$serf_prefix" ; then
+ dnl User provided a prefix, so the location is non default.
+ dnl serf doesn't create .la since 2011, and it just
+ dnl gives '-lserf-1'. At the same time, libtool doesn't
+ dnl add -rpath for dependencies given as '-l'.
+ dnl The workaround dnl is to hack '-L' into '-R'.
+ SVN_SERF_LIBS=["$SVN_SERF_LIBS `$PKG_CONFIG $serf_pc_arg
--libs-only-L | $SED -e 's/^-L/-R/g'`"]
+ fi
dnl don't use --libs-only-L because then we might miss some options
LDFLAGS=["$LDFLAGS `$PKG_CONFIG $serf_pc_arg --libs | $SED -e
's/-l[^ ]*//g'`"]
break
