Dear People,
I've tried my hand at building Subversion 1.1.0-rc2 packages. I've imitated the packaging of the official Debian packages as far as possible. Whenever possible I applied the Debian patches. However, since I don't understand exactly what I am doing, I suppose some breakage was inevitable.
The main thing that failed were the swig bindings. So the python and perl binding packages, namely python2.3-subversion and libsvn-core-perl packages are empty. However, subversion itself passed all tests. I haven't done much with it yet, but look forward to playing with it.
If anyone is willing to take a look I'd appreciate it. Since the only Debian patch that did not apply cleanly was debian/paches/rpath.patch in the source directory, this seems the most likely cause of the problem.
You can get my packages (binaries and source) by using the lines below.
deb http://www.cbcb.duke.edu/~faheem/debian/ ./ deb-src http://www.cbcb.duke.edu/~faheem/debian/ ./
I attach the patch rpath.path below. The comments are the original one by the maintainer, David Kimdon.
Here is the relevant entry from the changelog.
* subversion/trunk/debian/patches/rpath.patch: Only change is in build/generator/gen_base.py, where I'm really just guessing. Other changes are just relocating the patch, and not significant.
I have a few further comments.
1) I realise that the official Debian packages will be out once the official release has happened, but I thought it would be nice to encourage Debian users to do some testing before the release. Like everyone else, I'm anxious to start using fsfs. And I thought it would be good practice.
If I can get everything working properly I'll post an accouncement of this to debian-user.
2) I think it would be a good idea if packages of subversion without the BDB dependency could be created.
Would different versions of all the Debian packages have to be created in that case? Ie. libapache2-svn, python2.3-subversion, subversion, libsvn0, subversion, libsvn0-dev, subversion, subversion-tools, libsvn-core-perl.
3) I noticed all the tests that were run (as far as I could tell) were python scripts. This may be a stupid question, but how did they work when the python bindings were not built successfully?
Faheem.
********************************************************************** * subversion-1.0.2/Makefile.in (LINK) : Remove -rpath. (LINK_LIB) : New variable. This is what we use to link libraries. 'libtool' keys off the '-rpath' argument to know that it should create a shared library. Removing the rpath parameter from the library link will cause libtool to produce a convenience library (a static archive) and no shared libs, that is not what we want. For any libraries in /usr/lib libtool knows not to actually put the rpath into the binary. * subversion-1.0.2/build/generator/gen_base.py (TargetLinked) : Use the '$(LINK_LIB)' command by default. (TargetExe) : Executables should be linked with '$(LINK)' command so no rpath is put into the binary. * subversion-1.0.2/build/generator/gen_make.py (Generator) : Fix the apache module link rule to explicitly link to the necessary subversion shared libraries.
--- subversion-1.0.2.orig/Makefile.in 2004-04-15 20:43:46.000000000 +0200 +++ subversion-1.0.2/Makefile.in 2004-04-25 20:47:08.000000000 +0200 @@ -134,7 +134,8 @@ COMPILE_SWIG_JAVA = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(SWIG_JAVA_INCLUDES) $(INCLUDES) -o $@ -c COMPILE_SWIG_PL = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(SWIG_PL_INCLUDES) $(INCLUDES) -o $@ -c
-LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(libdir) +LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) +LINK_LIB = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(libdir)
# special link rule for mod_dav_svn
LINK_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS)
$(LDFLAGS) -rpath $(APACHE_LIBEXECDIR) -avoid-version -module
--- subversion-1.0.2.orig/build/generator/gen_base.py 2003-10-31 09:51:39.000000000
+0100
+++ subversion-1.0.2/build/generator/gen_base.py 2004-04-25 21:04:45.972682190
+0200
@@ -332,8 +332,8 @@
self.install = options.get('install')
self.compile_cmd = options.get('compile-cmd')
self.sources = options.get('sources', '*.c')
- self.link_cmd = options.get('link-cmd', '$(LINK)')
-
+ #self.link_cmd = options.get('link-cmd', '$(LINK)')
+ self.link_cmd = '$(LINK_LIB)'
self.external_lib = options.get('external-lib')
self.external_project = options.get('external-project')
self.msvc_libs = string.split(options.get('msvc-libs', ''))
@@ -382,7 +382,8 @@ self.objext = extmap['exe', 'object']
self.filename = build_path_join(self.path, name + extmap['exe', 'target'])
-
+ self.link_cmd = '$(LINK)'
+
self.manpages = options.get('manpages', '')
self.testing = options.get('testing')--- subversion-1.1.0-rc2/build/generator/gen_make.py.old 2004-08-18
15:08:06.000000000 -0400
+++ subversion-1.1.0-rc2/build/generator/gen_make.py 2004-08-18 15:08:15.000000000
-0400
@@ -72,8 +72,16 @@
# append the output of the target to our stated dependencies
deps.append(source.filename)- # link against the library
- libs.append(build_path_join(retreat, source.filename))
+ if isinstance(target_ob, gen_base.TargetApacheMod):
+ dirname, fname = os.path.split(source.filename)
+ libname = string.replace(fname, '.la', '')
+ libname = string.replace(libname, 'lib', '')
+ dirname = os.path.join(retreat, dirname, '.libs')
+ libs.append('-Wl,-L' + dirname)
+ libs.append('-Wl,-l' + libname)
+ else:
+ # link against the library
+ libs.append(build_path_join(retreat, source.filename))
elif isinstance(source, gen_base.ObjectFile):
# link in the object file
objects.append(source.filename)-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
