Peter Samuelson wrote:
> I'll probably try and patch the dlopen
> call can be patched to use a relative path instead of absolute, so that
> it respects things like LD_LIBRARY_PATH.
*nods* Actually it already uses a relative path, but libtool uses rpath
instead of LD_LIBRARY_PATH (why? I don't know). Evil hacky thing just
to get it working is below.
> > | gcc: error: subversion/bindings/swig/python/svn_client.c: No such file or
> > directory
> > | gcc: fatal error: no input files
[...]
> Yeah, I'll investigate. Probably a VPATH issue of some sort. Thanks.
With that hint, I was able to fix it. Not sure that assuming all
non-linker rules have only one source file is a valid thing to do, but
it seems to work. :)
This demo also uses the system libtool like previous versions of the
Debian package would, instead of the bundled copy. That's not to fix
any particular issue --- it just buys some peace of mind since it
means one less component to take responsibility for.
To get debian/patches/apr-api to apply to the 1.7.x branch instead of
the trunk, I also needed the following on top of the patch from last
time:
--- a/debian/patches/apr-abi
+++ b/debian/patches/apr-abi
@@ -42,9 +42,10 @@ Submitted at
http://svn.haxx.se/dev/archive-2006-03/0522.shtml
--- a/configure.ac
+++ b/configure.ac
-@@ -106,7 +106,12 @@ if test `expr $apr_version : 2` -ne 0; then
+@@ -106,8 +106,13 @@ if test `expr $apr_version : 2` -ne 0; then
AC_SUBST(SVN_APRUTIL_CONFIG, ["$apu_config"])
AC_SUBST(SVN_APRUTIL_LIBS)
+ AC_SUBST(SVN_APRUTIL_PREFIX)
else
- SVN_LT_SOVERSION="-version-info 0"
+ dnl We are Debian.
Even with this patch, the javahl tests emit errors like this:
| 1)
testCreate(org.apache.subversion.javahl.SVNReposTests)org.apache.subversion.javahl.ClientException:
Incompatib
| svn: Version mismatch in 'svn_gnome_keyring': found 1.6.17, expected 1.7.0-dev
|
| at org.apache.subversion.javahl.SVNTests.setUp(SVNTests.java:241)
| at org.apache.subversion.javahl.RunTests.main(RunTests.java:116)
since I didn't find where in build.conf to communicate the location of
the auth modules to the JRE.
Thanks again for the hints. It helps a lot.
---
build.conf | 5 ++++-
build/generator/templates/makefile.ezt | 2 +-
configure.ac | 14 +-------------
3 files changed, 6 insertions(+), 15 deletions(-)
--- a/build.conf
+++ b/build.conf
@@ -103,13 +103,16 @@ swig-checkout-files = common.swg swigrun.swg runtime.swg
# libraries are present.
# This bug was last confirmed to be present in libtool 1.5.22.
+# Yuck yuck yuck, Same applies to -lsvn_auth_gnome_keyring-1,
-lsvn_auth_kwallet,
+# etc.
+
# The subversion command-line client
[svn]
description = Subversion Client
type = exe
path = subversion/svn
libs = libsvn_client libsvn_wc libsvn_ra libsvn_delta libsvn_diff libsvn_subr
- apriconv apr
+ apriconv apr libsvn_auth_gnome_keyring libsvn_auth_kwallet
manpages = subversion/svn/svn.1
install = bin
--- a/build/generator/templates/makefile.ezt
+++ b/build/generator/templates/makefile.ezt
@@ -154,5 +154,5 @@ install-include:[for includes] [includes.file][end]
########################################
[for deps]
[deps.name]:[for deps.deps] [deps.deps][end][if-any deps.cmd]
- [deps.cmd] [if-any
deps.generated][else]$(canonicalized_srcdir)[end][deps.source][end]
+ [deps.cmd] $<[end]
[end]
--- a/configure.ac
+++ b/configure.ac
@@ -222,19 +222,7 @@ AC_DEFINE_UNQUOTED(SVN_LOCALE_DIR, "${svn_localedir}",
dnl Check for libtool -- we'll definitely need it for all our shared libs!
AC_MSG_NOTICE([configuring libtool now])
ifdef([LT_INIT], [LT_INIT], [AC_PROG_LIBTOOL])
-AC_ARG_ENABLE(experimental-libtool,
- AS_HELP_STRING([--enable-experimental-libtool],[Use APR's libtool]),
- [experimental_libtool=$enableval],[experimental_libtool=no])
-
-if test "$experimental_libtool" = "yes"; then
- echo "using APR's libtool"
- sh_libtool="`$apr_config --apr-libtool`"
- LIBTOOL="$sh_libtool"
- SVN_LIBTOOL="$sh_libtool"
-else
- sh_libtool="$abs_builddir/libtool"
- SVN_LIBTOOL="\$(SHELL) $sh_libtool"
-fi
+SVN_LIBTOOL=libtool
AC_SUBST(SVN_LIBTOOL)
dnl Determine the libtool version
--
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
