You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Yoshiki Hayashi <yo...@xemacs.org> on 2001/10/19 10:27:13 UTC
[PATCH] Add native ruby binding to Subversion distribution
Here's a patch to build native Ruby binding inside
Subversion distribution. All you have to do is:
1. unpack svn-ruby-0.2.tar.gz from
http://www.sodan.org/~penny/tmp/svn-ruby-0.2.tar.gz to
subversion/bindings/ruby and rename svn-ruby-0.2 to
native.
2. Apply following patch.
3. Add attached rb-config.rb and svn-ruby.m4 files to
ac-helpers directory.
The default is not to build Ruby binding so you need to add
--enable-ruby-binding to configure. The reason is I'm not
sure it can be built on every system. I can only test it on
Debian unstable. However, it would be very nice if it can
be added to Subversion distribution and people can test it
so that I can shake out some bugs. I expect the default to
be --enable-ruby-binding in the future.
It installs Svn.la to
/usr/local/lib/site_ruby/1.6/i386-linux on my machine.
Probably Debian package or other package on FHS compliant
system doesn't like it but I decided to ignore it at this
point.
What this patch does is to add dso type to gen-make.py and
build.conf. The main purpose is to add new link rule and to
be able to add more targets which creates Svn.la. The name
of dso rule consists of language name and .la name
concatenated with underscore like Ruby_Svn. This allows you
to add Python_Svn to create another Svn.la at the later time.
There's one problem with this patch, though. It adds hack
in SVN_FIND_RUBY to add -lpthread to LDFLAGS if -pthread is
present in CFLAGS. You can link without -lpthread but if
you try to load the Svn.so from Ruby interpreter, it barfs
on error that it cannot find libpthread.so. If
ruby/native/Svn.so is linked with -lpthread, it will be
loaded successfully. I don't know the correct answer to
this problem. I thought APR should add -lpthread but the
magical undocumented -pthread flag of GCC allows you to
compile and link C programs without problem. The linking
problem only occurs when a library linked with thread
enabled APR is dlopened by the program not linked with
pthread. Any ideas?
I appreciate any feedback.
ChangeLog and patch are attached below.
Makefile.in
(RUBY_INCLUDES, ruby_moddir): New var.
(LDFLAGS): Now the value is determined by configure.
(COMPILE_RUBY_MOD, MODULE): New var.
(INSTAL_RUBY_MOD, RUBY): New var.
gen-make.py
* Use $(MODULE) to link when target type is dso.
* Add new 'ruby-mod' custom rule to compile Ruby module.
* Add new target type dso. It is similar to lib but has
different target name convention and link command.
build.conf
* New target Ruby_Svn.
configure.in
* Include new helper macro from svn-ruby.m4
* Call AC_LIBTOOL_DLOPEN to check whether the system
supports dlopen.
* Call SVN_FIND_RUBY to determine if it can/should build
Ruby binding.
* (BUILD_RULES, INSTALL_RULES): Add Ruby rule when
Berkeley DB is present. Fs binding depends on it.
svn-ruby.m4
New file.
(SVN_FIND_RUBY): New function. If --enable-ruby-binding is
given and correct inperter is found, add rules to build
and install Ruby binding.
rb-config.m4
New file.
Return the location of header file or install directory
depending on the command line argument.
Index: ./Makefile.in
===================================================================
--- ./.svn/text-base/Makefile.in Wed Oct 10 19:55:16 2001
+++ ./Makefile.in Fri Oct 19 09:55:58 2001
@@ -51,18 +51,23 @@
APACHE_INCLUDES = @APACHE_INCLUDES@
APACHE_TARGET = @APACHE_TARGET@
+RUBY_INCLUDES = @RUBY_INCLUDES@
+ruby_moddir = @ruby_moddir@
+
MKDIR = @MKDIR@
CFLAGS = @CFLAGS@
CPPFLAGS = @CPPFLAGS@
-LDFLAGS =
+LDFLAGS = @LDFLAGS@
COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES)
LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) -o $@ -c $<
COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c $<
+COMPILE_RUBY_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(RUBY_INCLUDES) $(INCLUDES) -o $@ -c $<
LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -rpath $(libdir)
+MODULE = $(LIBTOOL) $(LTFLAGS) $(LT_LDFLAGS) $(COMPILE) -module -avoid-version $(LDFLAGS) -rpath $(libdir)
INSTALL = @INSTALL@
INSTALL_LIB = $(LIBTOOL) --mode=install $(INSTALL)
@@ -72,8 +77,10 @@
INSTALL_INCLUDE = $(INSTALL) -m 644
INSTALL_MOD_SHARED = @APXS@ -i -a
INSTALL_MOD_STATIC = $(INSTALL) -m 644
+INSTALL_RUBY_MOD = $(INSTALL_LIB)
PYTHON = @PYTHON@
+RUBY = @RUBY@
all: external-all local-all
clean: external-clean local-clean
Index: ./ac-helpers/svn-ruby.m4
===================================================================
Index: ./ac-helpers/rb-config.rb
===================================================================
Index: ./gen-make.py
===================================================================
--- ./.svn/text-base/gen-make.py Mon Oct 8 17:55:01 2001
+++ ./gen-make.py Thu Oct 18 21:45:14 2001
@@ -115,6 +115,11 @@
# something we don't know, so just include it directly
libs.append(lib)
+ if parser.get(target, 'type') == 'dso':
+ link = '$(MODULE)'
+ else:
+ link = '$(LINK)'
+
targ_varname = string.replace(target, '-', '_')
ldflags = parser.get(target, 'link-flags')
add_deps = parser.get(target, 'add-deps')
@@ -122,11 +127,11 @@
ofile.write('%s_DEPS = %s %s\n'
'%s_OBJECTS = %s\n'
'%s: $(%s_DEPS)\n'
- '\tcd %s && $(LINK) -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
+ '\tcd %s && %s -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
% (targ_varname, string.join(objects + deps), add_deps,
targ_varname, objnames,
tpath, targ_varname,
- path, tfile, ldflags, targ_varname, string.join(libs)))
+ path, link, tfile, ldflags, targ_varname, string.join(libs)))
custom = parser.get(target, 'custom')
if custom == 'apache-mod':
@@ -137,6 +142,14 @@
ofile.write('%s%s: %s\n\t$(COMPILE_APACHE_MOD)\n'
% (src[:-2], objext, src))
ofile.write('\n')
+ elif custom == 'ruby-mod':
+ # special build, needing Ruby includes
+ ofile.write('# build these special -- use RUBY_INCLUDES\n')
+ for src in sources:
+ if src[-2:] == '.c':
+ ofile.write('%s%s: %s\n\t$(COMPILE_RUBY_MOD)\n'
+ % (src[:-2], objext, src))
+ ofile.write('\n')
for g_name, g_targets in install.items():
target_names = [ ]
@@ -303,6 +316,10 @@
install = 'lib'
elif type == 'doc':
pass
+ elif type == 'dso':
+ ignore, tname = string.split(name, '_')
+ tfile = tname + '.la'
+ self.objext = '.lo'
else:
raise GenMakeError('ERROR: unknown build type: ' + type)
@@ -325,6 +342,7 @@
_default_sources = {
'lib' : '*.c',
'exe' : '*.c',
+ 'dso' : '*.c',
'doc' : '*.texi',
}
Index: ./build.conf
===================================================================
--- ./.svn/text-base/build.conf Mon Oct 8 17:55:03 2001
+++ ./build.conf Thu Oct 18 21:45:56 2001
@@ -145,6 +145,14 @@
# there are some .c files included by others, so *.c isn't appropriate
sources = hashtable.c xmlparse.c xmlrole.c xmltok.c
+[Ruby_Svn]
+type = dso
+path = subversion/bindings/ruby/native
+libs = libsvn_client libsvn_wc libsvn_ra libsvn_repos libsvn_fs
+ libsvn_delta libsvn_subr $(SVN_APR_LIBS)
+custom = ruby-mod
+install = ruby-mod
+
# ----------------------------------------------------------------------------
#
# TESTING TARGETS
Index: ./configure.in
===================================================================
--- ./.svn/text-base/configure.in Fri Oct 12 14:45:57 2001
+++ ./configure.in Fri Oct 19 10:10:11 2001
@@ -25,6 +25,7 @@
sinclude(ac-helpers/berkeley-db.m4)
sinclude(ac-helpers/svn-apache.m4)
sinclude(ac-helpers/svn-macros.m4)
+sinclude(ac-helpers/svn-ruby.m4)
dnl Grab the libtool macros
sinclude(ac-helpers/libtool.m4)
@@ -109,6 +110,7 @@
dnl Check for libtool -- we'll definitely need it for all our shared libs!
echo "configuring libtool now"
+AC_LIBTOOL_DLOPEN
AC_PROG_LIBTOOL
dnl Configure neon --------------------------
@@ -143,6 +145,12 @@
dnl find Apache
SVN_FIND_APACHE
+dnl find Ruby
+
+SVN_FIND_RUBY
+
+AC_SUBST(LDFLAGS)
+
dnl ### should we ever bother with the system install?
dnl use abs_srcdir. sometimes during installation, libtool will relink the
dnl library. when it does this, it does a "cd", so a relative use of
@@ -169,8 +177,8 @@
INSTALL_RULES="install-lib install-bin install-include"
BUILD_RULES="lib bin test"
if test "$svn_lib_berkeley_db" = "yes"; then
- BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE test fs-test"
- INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE install-include"
+ BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE $BUILD_RUBY_RULE test fs-test"
+ INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE $INSTALL_RUBY_RULE install-include"
FS_TEST_DEPS="\$(FS_TEST_DEPS)"
FS_TEST_PROGRAMS="\$(FS_TEST_PROGRAMS)"
fi
Re: [PATCH] Add native ruby binding to Subversion distribution
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Oct 29, 2001 at 04:41:27PM -0600, Karl Fogel wrote:
> Thanks, Yoshiki!
>
> Given past experience and the complexity of our configuration system,
> I think it's good practice for any non-trivial configuration change to
> be reviewed by another pair of eyes. Maybe -- Kevin Pilch-Bisson?
> Got time to look over this? (I'd do it myself, but I'm a sieve when
> it comes to spotting config issues :-( ...)
>
I'd be happy to look it over. I'll try to get to it tomorrow, but I
can't promise anything. :(
>
> -K
>
> Yoshiki Hayashi <yo...@xemacs.org> writes:
> > Here's the new version of build system patch. The basic
> > idea is the same as my previous patch so the explanation is
> > included mostly as is. Please read bindings/ruby/native as
> > bindings/ruby.
> >
> > I asked about LDFLAG kludge to Greg Stein on IRC but today
> > IRC server is flaky and couldn't ask the question I wanted
> > to ask. This patch adds -lpthread to LDFLAG if APR is
> > compiled with pthread. The problem is, if you load Svn.so
> > linked without -lpthread option, Ruby interpreter cannot
> > find libpthread and stop execution saying missing symbol or
> > something.
> >
> > Greg said -lpthread should be picked up by APR and I thought
> > so but it is not. The problem is the way APR checks CFLAGS
> > to gcc and LDFLAGS. First, APR tries to add one of
> > following CFLAGS will be necessary to build pthread support.
> > -kthread -pthread -pthreads -mthreads -Kthread -threads -mt
> >
> > Second, it tries to add -lpthread -lpthreads -lc_r to
> > LDFLAGS if first step failed.
> >
> > Here's how it works on my system (Debian unstable):
> >
> > 1. APR picks up -pthread as CFLAGS. It allows you to
> > compile and link pthread programs.
> >
> > 2. If I enable second check regardless of the result of
> > first check, -lpthread will not be added to LDFLAGS
> > because -pthread CFLAGS is all you need.
> >
> > 3. If I reverse the order of CFLAGS and LDFLAGS checking,
> > APR correctly picks up -lpthread and Ruby binding are
> > happy without LDFLAGS kludge.
> >
> > It looks like I should post patch to dev@apr to do #3. I
> > don't know if it will bring any portability problem but APR
> > people can probably figure it out. Anyway, I must go now.
> > The time of the last train is approaching. ;-)
> >
> > Yoshiki Hayashi <yo...@xemacs.org> writes:
> >
> > > Here's a patch to build native Ruby binding inside
> > > Subversion distribution. All you have to do is:
> >
> > > 2. Apply following patch.
> > >
> > > 3. Add attached rb-config.rb and svn-ruby.m4 files to
> > > ac-helpers directory.
> > >
> > > The default is not to build Ruby binding so you need to add
> > > --enable-ruby-binding to configure. The reason is I'm not
> > > sure it can be built on every system. I can only test it on
> > > Debian unstable. However, it would be very nice if it can
> > > be added to Subversion distribution and people can test it
> > > so that I can shake out some bugs. I expect the default to
> > > be --enable-ruby-binding in the future.
> > >
> > > It installs Svn.la to
> > > /usr/local/lib/site_ruby/1.6/i386-linux on my machine.
> > > Probably Debian package or other package on FHS compliant
> > > system doesn't like it but I decided to ignore it at this
> > > point.
> > >
> > > What this patch does is to add dso type to gen-make.py and
> > > build.conf. The main purpose is to add new link rule and to
> > > be able to add more targets which creates Svn.la. The name
> > > of dso rule consists of language name and .la name
> > > concatenated with underscore like Ruby_Svn. This allows you
> > > to add Python_Svn to create another Svn.la at the later time.
> > >
> > > There's one problem with this patch, though. It adds hack
> > > in SVN_FIND_RUBY to add -lpthread to LDFLAGS if -pthread is
> > > present in CFLAGS. You can link without -lpthread but if
> > > you try to load the Svn.so from Ruby interpreter, it barfs
> > > on error that it cannot find libpthread.so. If
> > > ruby/native/Svn.so is linked with -lpthread, it will be
> > > loaded successfully. I don't know the correct answer to
> > > this problem. I thought APR should add -lpthread but the
> > > magical undocumented -pthread flag of GCC allows you to
> > > compile and link C programs without problem. The linking
> > > problem only occurs when a library linked with thread
> > > enabled APR is dlopened by the program not linked with
> > > pthread. Any ideas?
> > >
> > > I appreciate any feedback.
> > >
> > > ChangeLog and patch are attached below.
> > >
> > > Makefile.in
> > >
> > > (RUBY_INCLUDES, ruby_moddir): New var.
> > > (LDFLAGS): Now the value is determined by configure.
> > > (COMPILE_RUBY_MOD, MODULE): New var.
> > > (INSTAL_RUBY_MOD, RUBY): New var.
> > >
> > > gen-make.py
> > >
> > > * Use $(MODULE) to link when target type is dso.
> > > * Add new 'ruby-mod' custom rule to compile Ruby module.
> > > * Add new target type dso. It is similar to lib but has
> > > different target name convention and link command.
> > >
> > > build.conf
> > >
> > > * New target Ruby_Svn.
> > >
> > > configure.in
> > >
> > > * Include new helper macro from svn-ruby.m4
> > > * Call AC_LIBTOOL_DLOPEN to check whether the system
> > > supports dlopen.
> > > * Call SVN_FIND_RUBY to determine if it can/should build
> > > Ruby binding.
> > > * (BUILD_RULES, INSTALL_RULES): Add Ruby rule when
> > > Berkeley DB is present. Fs binding depends on it.
> > >
> > > svn-ruby.m4
> > >
> > > New file.
> > >
> > > (SVN_FIND_RUBY): New function. If --enable-ruby-binding is
> > > given and correct inperter is found, add rules to build
> > > and install Ruby binding.
> > >
> > > rb-config.m4
> > >
> > > New file.
> > >
> > > Return the location of header file or install directory
> > > depending on the command line argument.
> >
> > Index: ./Makefile.in
> > ===================================================================
> > --- ./.svn/text-base/Makefile.in Mon Oct 29 20:13:52 2001
> > +++ ./Makefile.in Mon Oct 29 21:08:56 2001
> > @@ -53,18 +53,23 @@
> > APACHE_INCLUDES = @APACHE_INCLUDES@
> > APACHE_TARGET = @APACHE_TARGET@
> >
> > +RUBY_INCLUDES = @RUBY_INCLUDES@
> > +ruby_moddir = @ruby_moddir@
> > +
> > MKDIR = @MKDIR@
> >
> > CFLAGS = @CFLAGS@
> > CPPFLAGS = @CPPFLAGS@
> > -LDFLAGS =
> > +LDFLAGS = @LDFLAGS@
> >
> > COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES)
> > LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) -o $@ -c $<
> >
> > COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c $<
> > +COMPILE_RUBY_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(RUBY_INCLUDES) $(INCLUDES) -o $@ -c $<
> >
> > LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -rpath $(libdir)
> > +MODULE = $(LIBTOOL) $(LTFLAGS) $(LT_LDFLAGS) $(COMPILE) -module -avoid-version $(LDFLAGS) -rpath $(libdir)
> >
> > INSTALL = @INSTALL@
> > INSTALL_LIB = $(LIBTOOL) --mode=install $(INSTALL)
> > @@ -74,8 +79,10 @@
> > INSTALL_INCLUDE = $(INSTALL) -m 644
> > INSTALL_MOD_SHARED = @APXS@ -i -a
> > INSTALL_MOD_STATIC = $(INSTALL) -m 644
> > +INSTALL_RUBY_MOD = $(INSTALL_LIB)
> >
> > PYTHON = @PYTHON@
> > +RUBY = @RUBY@
> >
> > all: external-all local-all
> > clean: external-clgan local-clean
> > Index: ./gen-make.py
> > =============================================== ===================
> > --- ./.svn/text-base/gen-make.py Mon Oct 8 17:55:01 2001
> > +++ ./gen-make.py Mon Oct 29 21:09:19 2001
> > @@ -115,6 +115,11 @@
> > # something we don't know, so just include it directly
> > libs.append(lib)
> >
> > + if parser.get(target, 'type') == 'dso':
> > + link = '$(MODULE)'
> > + else:
> > + link = '$(LINK)'
> > +
> > targ_varname = string.replace(target, '-', '_')
> > ldflags = parser.get(target, 'link-flags')
> > add_deps = parser.get(target, 'add-deps')
> > @@ -122,11 +127,11 @@
> > ofile.write('%s_DEPS = %s %s\n'
> > '%s_OBJECTS = %s\n'
> > '%s: $(%s_DEPS)\n'
> > - '\tcd %s && $(LINK) -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
> > + '\tcd %s && %s -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
> > % (targ_varname, string.join(objects + deps), add_deps,
> > targ_varname, objnames,
> > tpath, targ_varname,
> > - path, tfile, ldflags, targ_varname, string.join(libs)))
> > + path, link, tfile, ldflags, targ_varname, string.join(libs)))
> >
> > custom = parser.get(target, 'custom')
> > if custom == 'apache-mod':
> > @@ -137,6 +142,14 @@
> > ofile.write('%s%s: %s\n\t$(COMPILE_APACHE_MOD)\n'
> > % (src[:-2], objext, src))
> > ofile.write('\n')
> > + elif custom == 'ruby-mod':
> > + # special build, needing Ruby includes
> > + ofile.write('# build these special -- use RUBY_INCLUDES\n')
> > + for src in sources:
> > + if src[-2:] == '.c':
> > + ofile.write('%s%s: %s\n\t$(COMPILE_RUBY_MOD)\n'
> > + % (src[:-2], objext, src))
> > + ofile.write('\n')
> >
> > for g_name, g_targets in install.items():
> > target_names = [ ]
> > @@ -303,6 +316,10 @@
> > install = 'lib'
> > elif type == 'doc':
> > pass
> > + elif type == 'dso':
> > + ignore, tname = string.split(name, '_')
> > + tfile = tname + '.la'
> > + self.objext = '.lo'
> > else:
> > raise GenMakeError('ERROR: unknown build type: ' + type)
> >
> > @@ -325,6 +342,7 @@
> > _default_sources = {
> > 'lib' : '*.c',
> > 'exe' : '*.c',
> > + 'dso' : '*.c',
> > 'doc' : '*.texi',
> > }
> >
> > Index: ./build.conf
> > ===================================================================
> > --- ./.svn/text-base/build.conf Mon Oct 29 20:13:52 2001
> > +++ ./build.conf Mon Oct 29 21:10:56 2001
> > @@ -145,6 +145,14 @@
> > # there are some .c files included by others, so *.c isn't appropriate
> > sources = hashtable.c xmlparse.c xmlrole.c xmltok.c
> >
> > +[Ruby_Svn]
> > +type = dso
> > +path = subversion/bindings/ruby
> > +libs = libsvn_client libsvn_wc libsvn_ra libsvn_repos libsvn_fs
> > + libsvn_delta libsvn_subr $(SVN_APR_LIBS)
> > +custom = ruby-mod
> > +install = ruby-mod
> > +
> > # ----------------------------------------------------------------------------
> > #
> > # TESTING TARGETS
> > Index: ./configure.in
> > ===================================================================
> > --- ./.svn/text-base/configure.in Mon Oct 29 20:14:01 2001
> > +++ ./configure.in Mon Oct 29 21:11:57 2001
> > @@ -31,6 +31,7 @@
> > sinclude(ac-helpers/svn-macros.m4)
> > sinclude(ac-helpers/neon.m4)
> > sinclude(ac-helpers/apr.m4)
> > +sinclude(ac-helpers/svn-ruby.m4)
> >
> > dnl Grab the libtool macros
> > sinclude(ac-helpers/libtool.m4)
> > @@ -95,6 +96,7 @@
> >
> > dnl Check for libtool -- we'll definitely need it for all our shared libs!
> > echo "configuring libtool now"
> > +AC_LIBTOOL_DLOPEN
> > AC_PROG_LIBTOOL
> >
> > NEON_WANTED=0.17.2
> > @@ -103,6 +105,12 @@
> > dnl find Apache
> > SVN_FIND_APACHE
> >
> > +dnl find Ruby
> > +
> > +SVN_FIND_RUBY
> > +
> > +AC_SUBST(LDFLAGS)
> > +
> > dnl Check for libraries --------------------
> >
> > dnl AC_CHECK_LIB() calls go here, if we ever need any
> > @@ -119,8 +127,8 @@
> > INSTALL_RULES="install-lib install-bin install-include"
> > BUILD_RULES="lib bin test"
> > if test "$svn_lib_berkeley_db" = "yes"; then
> > - BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE test fs-test"
> > - INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE install-include"
> > + BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE $BUILD_RUBY_RULE test fs-test"
> > + INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE $INSTALL_RUBY_RULE install-include"
> > FS_TEST_DEPS="\$(FS_TEST_DEPS)"
> > FS_TEST_PROGRAMS="\$(FS_TEST_PROGRAMS)"
> > fi
> > AC_DEFUN(SVN_FIND_RUBY,[
> >
> > AC_ARG_ENABLE(ruby-binding,
> > [ --enable-ruby-binding Turn on native Ruby binding support],
> > [
> > if test "$enableval" = "yes"; then
> > ruby_binding="yes"
> > fi
> > ])
> >
> > AC_PATH_PROG(RUBY, ruby)
> > if test "$ruby_binding" = "yes"; then
> > if test "$RUBY" = ""; then
> > AC_MSG_ERROR(Unable to find ruby interpreter)
> > fi
> > if test "$enable_shared" = "no"; then
> > AC_MSG_ERROR(Ruby binding requires shared library)
> > fi
> > AC_MSG_CHECKING(for Ruby header)
> > ruby_header="`$RUBY ${abs_srcdir}/ac-helpers/rb-config.rb include`"
> > if test "$ruby_header" = ""; then
> > AC_MSG_ERROR([no - Unable to locate ruby.h])
> > else
> > AC_MSG_RESULT($ruby_header)
> > RUBY_INCLUDES="-I$ruby_header"
> > /* ### Kludge to avoid linking error with pthread. */
> > case "$EXTRA_CFLAGS" in
> > *-pthread*)
> > LDFLAGS="$LDFLAGS -lpthread"
> > ;;
> > esac
> > BUILD_RUBY_RULE=ruby-mod
> > INSTALL_RUBY_RULE=install-ruby-mod
> > ruby_moddir="`$RUBY ${abs_srcdir}/ac-helpers/rb-config.rb site-install`"
> > fi
> > fi
> > AC_SUBST(RUBY_INCLUDES)
> > AC_SUBST(BUILD_RUBY_RULE)
> > AC_SUBST(INSTALL_RUBY_RULE)
> > AC_SUBST(ruby_moddir)
> >
> > ])
> > begin
> > require 'rbconfig'
> > rescue LoadError
> > exit 1
> > end
> >
> > command = ARGV.shift
> >
> > if command == 'include' then
> > if File.exists?(File.join(Config::CONFIG['archdir'], 'ruby.h')) then
> > print Config::CONFIG['archdir']
> > end
> > elsif command == 'site-install' then
> > print Config::CONFIG['sitearchdir']
> > end
> >
> >
> > --
> > Yoshiki Hayashi
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: [PATCH] Add native ruby binding to Subversion distribution
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Thanks, Yoshiki!
Given past experience and the complexity of our configuration system,
I think it's good practice for any non-trivial configuration change to
be reviewed by another pair of eyes. Maybe -- Kevin Pilch-Bisson?
Got time to look over this? (I'd do it myself, but I'm a sieve when
it comes to spotting config issues :-( ...)
-K
Yoshiki Hayashi <yo...@xemacs.org> writes:
> Here's the new version of build system patch. The basic
> idea is the same as my previous patch so the explanation is
> included mostly as is. Please read bindings/ruby/native as
> bindings/ruby.
>
> I asked about LDFLAG kludge to Greg Stein on IRC but today
> IRC server is flaky and couldn't ask the question I wanted
> to ask. This patch adds -lpthread to LDFLAG if APR is
> compiled with pthread. The problem is, if you load Svn.so
> linked without -lpthread option, Ruby interpreter cannot
> find libpthread and stop execution saying missing symbol or
> something.
>
> Greg said -lpthread should be picked up by APR and I thought
> so but it is not. The problem is the way APR checks CFLAGS
> to gcc and LDFLAGS. First, APR tries to add one of
> following CFLAGS will be necessary to build pthread support.
> -kthread -pthread -pthreads -mthreads -Kthread -threads -mt
>
> Second, it tries to add -lpthread -lpthreads -lc_r to
> LDFLAGS if first step failed.
>
> Here's how it works on my system (Debian unstable):
>
> 1. APR picks up -pthread as CFLAGS. It allows you to
> compile and link pthread programs.
>
> 2. If I enable second check regardless of the result of
> first check, -lpthread will not be added to LDFLAGS
> because -pthread CFLAGS is all you need.
>
> 3. If I reverse the order of CFLAGS and LDFLAGS checking,
> APR correctly picks up -lpthread and Ruby binding are
> happy without LDFLAGS kludge.
>
> It looks like I should post patch to dev@apr to do #3. I
> don't know if it will bring any portability problem but APR
> people can probably figure it out. Anyway, I must go now.
> The time of the last train is approaching. ;-)
>
> Yoshiki Hayashi <yo...@xemacs.org> writes:
>
> > Here's a patch to build native Ruby binding inside
> > Subversion distribution. All you have to do is:
>
> > 2. Apply following patch.
> >
> > 3. Add attached rb-config.rb and svn-ruby.m4 files to
> > ac-helpers directory.
> >
> > The default is not to build Ruby binding so you need to add
> > --enable-ruby-binding to configure. The reason is I'm not
> > sure it can be built on every system. I can only test it on
> > Debian unstable. However, it would be very nice if it can
> > be added to Subversion distribution and people can test it
> > so that I can shake out some bugs. I expect the default to
> > be --enable-ruby-binding in the future.
> >
> > It installs Svn.la to
> > /usr/local/lib/site_ruby/1.6/i386-linux on my machine.
> > Probably Debian package or other package on FHS compliant
> > system doesn't like it but I decided to ignore it at this
> > point.
> >
> > What this patch does is to add dso type to gen-make.py and
> > build.conf. The main purpose is to add new link rule and to
> > be able to add more targets which creates Svn.la. The name
> > of dso rule consists of language name and .la name
> > concatenated with underscore like Ruby_Svn. This allows you
> > to add Python_Svn to create another Svn.la at the later time.
> >
> > There's one problem with this patch, though. It adds hack
> > in SVN_FIND_RUBY to add -lpthread to LDFLAGS if -pthread is
> > present in CFLAGS. You can link without -lpthread but if
> > you try to load the Svn.so from Ruby interpreter, it barfs
> > on error that it cannot find libpthread.so. If
> > ruby/native/Svn.so is linked with -lpthread, it will be
> > loaded successfully. I don't know the correct answer to
> > this problem. I thought APR should add -lpthread but the
> > magical undocumented -pthread flag of GCC allows you to
> > compile and link C programs without problem. The linking
> > problem only occurs when a library linked with thread
> > enabled APR is dlopened by the program not linked with
> > pthread. Any ideas?
> >
> > I appreciate any feedback.
> >
> > ChangeLog and patch are attached below.
> >
> > Makefile.in
> >
> > (RUBY_INCLUDES, ruby_moddir): New var.
> > (LDFLAGS): Now the value is determined by configure.
> > (COMPILE_RUBY_MOD, MODULE): New var.
> > (INSTAL_RUBY_MOD, RUBY): New var.
> >
> > gen-make.py
> >
> > * Use $(MODULE) to link when target type is dso.
> > * Add new 'ruby-mod' custom rule to compile Ruby module.
> > * Add new target type dso. It is similar to lib but has
> > different target name convention and link command.
> >
> > build.conf
> >
> > * New target Ruby_Svn.
> >
> > configure.in
> >
> > * Include new helper macro from svn-ruby.m4
> > * Call AC_LIBTOOL_DLOPEN to check whether the system
> > supports dlopen.
> > * Call SVN_FIND_RUBY to determine if it can/should build
> > Ruby binding.
> > * (BUILD_RULES, INSTALL_RULES): Add Ruby rule when
> > Berkeley DB is present. Fs binding depends on it.
> >
> > svn-ruby.m4
> >
> > New file.
> >
> > (SVN_FIND_RUBY): New function. If --enable-ruby-binding is
> > given and correct inperter is found, add rules to build
> > and install Ruby binding.
> >
> > rb-config.m4
> >
> > New file.
> >
> > Return the location of header file or install directory
> > depending on the command line argument.
>
> Index: ./Makefile.in
> ===================================================================
> --- ./.svn/text-base/Makefile.in Mon Oct 29 20:13:52 2001
> +++ ./Makefile.in Mon Oct 29 21:08:56 2001
> @@ -53,18 +53,23 @@
> APACHE_INCLUDES = @APACHE_INCLUDES@
> APACHE_TARGET = @APACHE_TARGET@
>
> +RUBY_INCLUDES = @RUBY_INCLUDES@
> +ruby_moddir = @ruby_moddir@
> +
> MKDIR = @MKDIR@
>
> CFLAGS = @CFLAGS@
> CPPFLAGS = @CPPFLAGS@
> -LDFLAGS =
> +LDFLAGS = @LDFLAGS@
>
> COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES)
> LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) -o $@ -c $<
>
> COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c $<
> +COMPILE_RUBY_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(RUBY_INCLUDES) $(INCLUDES) -o $@ -c $<
>
> LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -rpath $(libdir)
> +MODULE = $(LIBTOOL) $(LTFLAGS) $(LT_LDFLAGS) $(COMPILE) -module -avoid-version $(LDFLAGS) -rpath $(libdir)
>
> INSTALL = @INSTALL@
> INSTALL_LIB = $(LIBTOOL) --mode=install $(INSTALL)
> @@ -74,8 +79,10 @@
> INSTALL_INCLUDE = $(INSTALL) -m 644
> INSTALL_MOD_SHARED = @APXS@ -i -a
> INSTALL_MOD_STATIC = $(INSTALL) -m 644
> +INSTALL_RUBY_MOD = $(INSTALL_LIB)
>
> PYTHON = @PYTHON@
> +RUBY = @RUBY@
>
> all: external-all local-all
> clean: external-clean local-clean
> Index: ./gen-make.py
> ===================================================================
> --- ./.svn/text-base/gen-make.py Mon Oct 8 17:55:01 2001
> +++ ./gen-make.py Mon Oct 29 21:09:19 2001
> @@ -115,6 +115,11 @@
> # something we don't know, so just include it directly
> libs.append(lib)
>
> + if parser.get(target, 'type') == 'dso':
> + link = '$(MODULE)'
> + else:
> + link = '$(LINK)'
> +
> targ_varname = string.replace(target, '-', '_')
> ldflags = parser.get(target, 'link-flags')
> add_deps = parser.get(target, 'add-deps')
> @@ -122,11 +127,11 @@
> ofile.write('%s_DEPS = %s %s\n'
> '%s_OBJECTS = %s\n'
> '%s: $(%s_DEPS)\n'
> - '\tcd %s && $(LINK) -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
> + '\tcd %s && %s -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
> % (targ_varname, string.join(objects + deps), add_deps,
> targ_varname, objnames,
> tpath, targ_varname,
> - path, tfile, ldflags, targ_varname, string.join(libs)))
> + path, link, tfile, ldflags, targ_varname, string.join(libs)))
>
> custom = parser.get(target, 'custom')
> if custom == 'apache-mod':
> @@ -137,6 +142,14 @@
> ofile.write('%s%s: %s\n\t$(COMPILE_APACHE_MOD)\n'
> % (src[:-2], objext, src))
> ofile.write('\n')
> + elif custom == 'ruby-mod':
> + # special build, needing Ruby includes
> + ofile.write('# build these special -- use RUBY_INCLUDES\n')
> + for src in sources:
> + if src[-2:] == '.c':
> + ofile.write('%s%s: %s\n\t$(COMPILE_RUBY_MOD)\n'
> + % (src[:-2], objext, src))
> + ofile.write('\n')
>
> for g_name, g_targets in install.items():
> target_names = [ ]
> @@ -303,6 +316,10 @@
> install = 'lib'
> elif type == 'doc':
> pass
> + elif type == 'dso':
> + ignore, tname = string.split(name, '_')
> + tfile = tname + '.la'
> + self.objext = '.lo'
> else:
> raise GenMakeError('ERROR: unknown build type: ' + type)
>
> @@ -325,6 +342,7 @@
> _default_sources = {
> 'lib' : '*.c',
> 'exe' : '*.c',
> + 'dso' : '*.c',
> 'doc' : '*.texi',
> }
>
> Index: ./build.conf
> ===================================================================
> --- ./.svn/text-base/build.conf Mon Oct 29 20:13:52 2001
> +++ ./build.conf Mon Oct 29 21:10:56 2001
> @@ -145,6 +145,14 @@
> # there are some .c files included by others, so *.c isn't appropriate
> sources = hashtable.c xmlparse.c xmlrole.c xmltok.c
>
> +[Ruby_Svn]
> +type = dso
> +path = subversion/bindings/ruby
> +libs = libsvn_client libsvn_wc libsvn_ra libsvn_repos libsvn_fs
> + libsvn_delta libsvn_subr $(SVN_APR_LIBS)
> +custom = ruby-mod
> +install = ruby-mod
> +
> # ----------------------------------------------------------------------------
> #
> # TESTING TARGETS
> Index: ./configure.in
> ===================================================================
> --- ./.svn/text-base/configure.in Mon Oct 29 20:14:01 2001
> +++ ./configure.in Mon Oct 29 21:11:57 2001
> @@ -31,6 +31,7 @@
> sinclude(ac-helpers/svn-macros.m4)
> sinclude(ac-helpers/neon.m4)
> sinclude(ac-helpers/apr.m4)
> +sinclude(ac-helpers/svn-ruby.m4)
>
> dnl Grab the libtool macros
> sinclude(ac-helpers/libtool.m4)
> @@ -95,6 +96,7 @@
>
> dnl Check for libtool -- we'll definitely need it for all our shared libs!
> echo "configuring libtool now"
> +AC_LIBTOOL_DLOPEN
> AC_PROG_LIBTOOL
>
> NEON_WANTED=0.17.2
> @@ -103,6 +105,12 @@
> dnl find Apache
> SVN_FIND_APACHE
>
> +dnl find Ruby
> +
> +SVN_FIND_RUBY
> +
> +AC_SUBST(LDFLAGS)
> +
> dnl Check for libraries --------------------
>
> dnl AC_CHECK_LIB() calls go here, if we ever need any
> @@ -119,8 +127,8 @@
> INSTALL_RULES="install-lib install-bin install-include"
> BUILD_RULES="lib bin test"
> if test "$svn_lib_berkeley_db" = "yes"; then
> - BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE test fs-test"
> - INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE install-include"
> + BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE $BUILD_RUBY_RULE test fs-test"
> + INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE $INSTALL_RUBY_RULE install-include"
> FS_TEST_DEPS="\$(FS_TEST_DEPS)"
> FS_TEST_PROGRAMS="\$(FS_TEST_PROGRAMS)"
> fi
> AC_DEFUN(SVN_FIND_RUBY,[
>
> AC_ARG_ENABLE(ruby-binding,
> [ --enable-ruby-binding Turn on native Ruby binding support],
> [
> if test "$enableval" = "yes"; then
> ruby_binding="yes"
> fi
> ])
>
> AC_PATH_PROG(RUBY, ruby)
> if test "$ruby_binding" = "yes"; then
> if test "$RUBY" = ""; then
> AC_MSG_ERROR(Unable to find ruby interpreter)
> fi
> if test "$enable_shared" = "no"; then
> AC_MSG_ERROR(Ruby binding requires shared library)
> fi
> AC_MSG_CHECKING(for Ruby header)
> ruby_header="`$RUBY ${abs_srcdir}/ac-helpers/rb-config.rb include`"
> if test "$ruby_header" = ""; then
> AC_MSG_ERROR([no - Unable to locate ruby.h])
> else
> AC_MSG_RESULT($ruby_header)
> RUBY_INCLUDES="-I$ruby_header"
> /* ### Kludge to avoid linking error with pthread. */
> case "$EXTRA_CFLAGS" in
> *-pthread*)
> LDFLAGS="$LDFLAGS -lpthread"
> ;;
> esac
> BUILD_RUBY_RULE=ruby-mod
> INSTALL_RUBY_RULE=install-ruby-mod
> ruby_moddir="`$RUBY ${abs_srcdir}/ac-helpers/rb-config.rb site-install`"
> fi
> fi
> AC_SUBST(RUBY_INCLUDES)
> AC_SUBST(BUILD_RUBY_RULE)
> AC_SUBST(INSTALL_RUBY_RULE)
> AC_SUBST(ruby_moddir)
>
> ])
> begin
> require 'rbconfig'
> rescue LoadError
> exit 1
> end
>
> command = ARGV.shift
>
> if command == 'include' then
> if File.exists?(File.join(Config::CONFIG['archdir'], 'ruby.h')) then
> print Config::CONFIG['archdir']
> end
> elsif command == 'site-install' then
> print Config::CONFIG['sitearchdir']
> end
>
>
> --
> Yoshiki Hayashi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add native ruby binding to Subversion distribution
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
Hi Yoshiki,
After looking at your patch I am basically in the same position as gstein.
It looks mostly okay, but we need to find out more info about this
problem with dso loading things that are linked to pthreads.
On Tue, Oct 30, 2001 at 04:56:34PM +0900, Yoshiki Hayashi wrote:
> Greg Stein <gs...@lyra.org> writes:
>
> > I'd like to know more about why the Ruby interpreter breaks this. If you
> > compile and link using -pthread (what APR discovers), then everything should
> > be just fine. What is going on with Ruby? Why does it mess up?
> >
> > We shouldn't monkey our build system because of a problem with Ruby's
> > loading of DSOs. If there is a problem in there, then we should fix it in
> > APR, but we can't know more until we have an accurate description of the
> > "missing symbol" and the related problems.
>
> Sorry I didn't explain enough. I was in hurry last night.
>
> It's not the problem of Ruby interpreter. Rather, it is the
> problem of GCC or the ld. I attached the smallest sample
> program apr-pthread-link-test.tar.gz so that you can see
> what happens.
>
> The Makefile in sample tar ball build the program called
> main which is not compiled with -pthread flag. It also
> compiles test.so which calls apr_initialize. It is compiled
> and linked with CFLAGS and LDFLAGS from APRVARS. (I copied
> the values in my system. You might need to change them.)
> That is what is happening with Ruby interpreter and Svn.so.
>
> If you run main, you'll see this:
> loaded
> ../main: relocation error: /usr/local/lib/libapr.so.0: undefined symbol: pthread_mutexattr_init
>
> ldd shows:
>
> ldd /usr/local/lib/libapr.so.0.0.0
> libc.so.6 => /lib/libc.so.6 (0x40028000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> ldd test.so
> libapr.so.0 => /usr/local/lib/libapr.so.0 (0x4000f000)
> libm.so.6 => /lib/libm.so.6 (0x4002a000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x4004c000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x4007a000)
> libdl.so.2 => /lib/libdl.so.2 (0x4008f000)
> libc.so.6 => /lib/libc.so.6 (0x40093000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>
> Looking at this, it's natural that loader cannot find
> pthread library because it isn't mentioned anywhere.
>
> So why Apache HTTP server runs fine? Because they are
> compiled with -pthread flag. If the loader of DSO does not
> compiled with -pthread, the problem happens like this. This
> doesn't happen if APR is linked with -lpthread.
>
> > > 3. If I reverse the order of CFLAGS and LDFLAGS checking,
> > > APR correctly picks up -lpthread and Ruby binding are
> > > happy without LDFLAGS kludge.
>
> > The order that APR checks them is correct, as far as I know. Patching it to
> > do #3 is simply futzing around with the order to get it to the state you
> > want. That doesn't mean that the "desired state" is correct.
>
> Yes, the current order is correct. However, gcc does some
> magical thing with -pthread flag which causes the problem.
> I don't know if it is gcc's fault or not. I couldn't find
> -pthread option in gcc info.
>
> > > LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -rpath $(libdir)
> > > +MODULE = $(LIBTOOL) $(LTFLAGS) $(LT_LDFLAGS) $(COMPILE) -module -avoid-version $(LDFLAGS) -rpath $(libdir)
> >
> > Let's call this LINK_DSO rather than MODULE. The latter doesn't describe the
> > operation that is occurring.
>
> OK.
>
> > We might be able to use this for the Apache module, too. I need to learn
> > more about the -module switch to see what that does to the output, compared
> > to what we do now.
>
> With -module flag, libtool does not require DSO to be
> prefixed with lib. In Ruby, DSO named foo.so is loaded by
> require 'foo
> so I don't want svn.so to be named libsvn.so.
>
> > >...
> > > @@ -303,6 +316,10 @@
> > > install = 'lib'
> > > elif type == 'doc':
> > > pass
> > > + elif type == 'dso':
> > > + ignore, tname = string.split(name, '_')
> > > + tfile = tname + '.la'
> > > + self.objext = '.lo'
> >
> > It would be good to have a comment in here on what is happening.
> > Specifically, that you're converting "ruby_svn" into "svn". Also, I think
> > you should use string.index() rather than split(). That would allow for
> > modules like "mod_dav_svn" which have more than underscore.
>
> Will do.
>
> > >...
> > > +++ ./build.conf Mon Oct 29 21:10:56 2001
> > > @@ -145,6 +145,14 @@
> > > # there are some .c files included by others, so *.c isn't appropriate
> > > sources = hashtable.c xmlparse.c xmlrole.c xmltok.c
> > >
> > > +[Ruby_Svn]
> >
> > Let's keep this all lower-case, like the other targets.
>
> Svn part is to name DSO Svn.so instead of svn.so. But I'll
> change it anyway. I'm not attached to the name.
>
> > >...
> > > dnl Check for libtool -- we'll definitely need it for all our shared libs!
> > > echo "configuring libtool now"
> > > +AC_LIBTOOL_DLOPEN
> >
> > Do we really need this? And the -module flag? It is interesting to note that
> > mod_dav_svn has been working quite fine for a long while, without the need
> > for this. Apache dlopen's it all the time.
>
> We need -module flag with the reason stated above. And I
> needed AC_LIBTOOL_DLOPEN or libtool didn't accept -module
> option.
>
> > >...
> > > +AC_SUBST(LDFLAGS)
> >
> > We need to watch out here, as I mentioned before.
>
> Yeah, this will be removed when we resolved -lpthread issue.
>
> Thanks for reviewing the patch.
>
>
> --
> Yoshiki Hayashi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Running Subversion on Mac OS X / Darwin
Posted by Stuart Roebuck <st...@adolos.co.uk>.
Has anyone succeeded in running recent builds of Subversion on Mac OS X?
Stuart.
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add native ruby binding to Subversion distribution
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
I've been extremely busy last two weeks but now I can spare
some time to Subversion again.
Yoshiki Hayashi <yo...@xemacs.org> writes:
> > >...
> > > +AC_SUBST(LDFLAGS)
> >
> > We need to watch out here, as I mentioned before.
>
> Yeah, this will be removed when we resolved -lpthread issue.
This issue is not resolved yet but here's the revised patch.
This does not contain -lpthread hack so you cannot build
Ruby binding if your apr picks up pthread.
The difference between this patch and previous patch are:
-lpthread to LDFLAG is removed
DSO target is renamed to svn_ruby from Ruby_Svn to allow
name with multiple underscore. This way, simple
string.index can find DSO name.
MODULE in Makefile.in is renamed to LINK_DSO
Makefile.in
(RUBY_INCLUDES, ruby_moddir): New var.
(COMPILE_RUBY_MOD, LINK_DSO): New var.
(INSTAL_RUBY_MOD, RUBY): New var.
gen-make.py
* Use $(LINK_DSO) to link when target type is dso.
* Add new 'ruby-mod' custom rule to compile Ruby module.
* Add new target type dso. It is similar to lib but has
different target name convention and link command.
build.conf
* New target svn_ruby.
configure.in
* Include new helper macro from svn-ruby.m4
* Call AC_LIBTOOL_DLOPEN to check whether the system
supports dlopen.
* Call SVN_FIND_RUBY to determine if it can/should build
Ruby binding.
* (BUILD_RULES, INSTALL_RULES): Add Ruby rule when
Berkeley DB is present. Fs binding depends on it.
svn-ruby.m4
New file.
(SVN_FIND_RUBY): New function. If --enable-ruby-binding is
given and correct inperter is found, add rules to build
and install Ruby binding.
rb-config.m4
New file.
Return the location of header file or install directory
depending on the command line argument.
Index: ./Makefile.in
===================================================================
--- ./.svn/text-base/Makefile.in Mon Nov 5 13:35:17 2001
+++ ./Makefile.in Tue Nov 13 20:41:39 2001
@@ -56,18 +56,23 @@
APACHE_INCLUDES = @APACHE_INCLUDES@
APACHE_TARGET = @APACHE_TARGET@
+RUBY_INCLUDES = @RUBY_INCLUDES@
+ruby_moddir = @ruby_moddir@
+
MKDIR = @MKDIR@
CFLAGS = @CFLAGS@
CPPFLAGS = @CPPFLAGS@
-LDFLAGS =
+LDFLAGS = @LDFLAGS@
COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES)
LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) -o $@ -c $<
COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c $<
+COMPILE_RUBY_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(RUBY_INCLUDES) $(INCLUDES) -o $@ -c $<
LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -rpath $(libdir)
+LINK_DSO = $(LIBTOOL) $(LTFLAGS) $(LT_LDFLAGS) $(COMPILE) -module -avoid-version $(LDFLAGS) -rpath $(libdir)
INSTALL = @INSTALL@
INSTALL_LIB = $(LIBTOOL) --mode=install $(INSTALL)
@@ -78,8 +83,10 @@
INSTALL_MOD_SHARED = @APXS@ -i -a
INSTALL_MOD_STATIC = $(INSTALL) -m 644
INSTALL_DATA = $(INSTALL) -m 644
+INSTALL_RUBY_MOD = $(INSTALL_LIB)
PYTHON = @PYTHON@
+RUBY = @RUBY@
all: external-all local-all
clean: external-clean local-clean
Index: ./gen-make.py
===================================================================
--- ./.svn/text-base/gen-make.py Mon Nov 5 13:36:51 2001
+++ ./gen-make.py Tue Nov 13 21:06:59 2001
@@ -123,6 +123,11 @@
for info in string.split(parser.get(target, 'infopages')):
infopages.append(info)
+ if parser.get(target, 'type') == 'dso':
+ link = '$(LINK_DSO)'
+ else:
+ link = '$(LINK)'
+
targ_varname = string.replace(target, '-', '_')
ldflags = parser.get(target, 'link-flags')
add_deps = parser.get(target, 'add-deps')
@@ -130,11 +135,11 @@
ofile.write('%s_DEPS = %s %s\n'
'%s_OBJECTS = %s\n'
'%s: $(%s_DEPS)\n'
- '\tcd %s && $(LINK) -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
+ '\tcd %s && %s -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
% (targ_varname, string.join(objects + deps), add_deps,
targ_varname, objnames,
tpath, targ_varname,
- path, tfile, ldflags, targ_varname, string.join(libs)))
+ path, link, tfile, ldflags, targ_varname, string.join(libs)))
custom = parser.get(target, 'custom')
if custom == 'apache-mod':
@@ -145,6 +150,14 @@
ofile.write('%s%s: %s\n\t$(COMPILE_APACHE_MOD)\n'
% (src[:-2], objext, src))
ofile.write('\n')
+ elif custom == 'ruby-mod':
+ # special build, needing Ruby includes
+ ofile.write('# build these special -- use RUBY_INCLUDES\n')
+ for src in sources:
+ if src[-2:] == '.c':
+ ofile.write('%s%s: %s\n\t$(COMPILE_RUBY_MOD)\n'
+ % (src[:-2], objext, src))
+ ofile.write('\n')
for g_name, g_targets in install.items():
target_names = [ ]
@@ -314,6 +327,15 @@
install = 'lib'
elif type == 'doc':
pass
+ elif type == 'dso':
+ # dso target name is separated with underscore, like svn_ruby.
+ # First part is the name of DSO.
+ # Second part is to uniquely distinguish makefile target.
+ # In above case, target will be svn_ruby_DEPS, svn_ruby_OBJECTS
+ # and svn.la.
+ tname = name[:string.index(name, '_')]
+ tfile = tname + '.la'
+ self.objext = '.lo'
else:
raise GenMakeError('ERROR: unknown build type: ' + type)
@@ -338,6 +360,7 @@
_default_sources = {
'lib' : '*.c',
'exe' : '*.c',
+ 'dso' : '*.c',
'doc' : '*.texi',
}
Index: ./build.conf
===================================================================
--- ./.svn/text-base/build.conf Tue Nov 13 20:29:53 2001
+++ ./build.conf Tue Nov 13 21:02:44 2001
@@ -154,6 +154,14 @@
# there are some .c files included by others, so *.c isn't appropriate
sources = hashtable.c xmlparse.c xmlrole.c xmltok.c
+[svn_ruby]
+type = dso
+path = subversion/bindings/ruby
+libs = libsvn_client libsvn_wc libsvn_ra libsvn_repos libsvn_fs
+ libsvn_delta libsvn_subr $(SVN_APR_LIBS)
+custom = ruby-mod
+install = ruby-mod
+
# ----------------------------------------------------------------------------
#
# TESTING TARGETS
Index: ./configure.in
===================================================================
--- ./.svn/text-base/configure.in Mon Nov 5 13:35:25 2001
+++ ./configure.in Tue Nov 13 20:48:34 2001
@@ -31,6 +31,7 @@
sinclude(ac-helpers/svn-macros.m4)
sinclude(ac-helpers/neon.m4)
sinclude(ac-helpers/apr.m4)
+sinclude(ac-helpers/svn-ruby.m4)
dnl Grab the libtool macros
sinclude(ac-helpers/libtool.m4)
@@ -95,6 +96,7 @@
dnl Check for libtool -- we'll definitely need it for all our shared libs!
echo "configuring libtool now"
+AC_LIBTOOL_DLOPEN
AC_PROG_LIBTOOL
NEON_WANTED="`sed -n '/NEON_WANTED=/s/.*=//p' $srcdir/buildcheck.sh`"
@@ -103,6 +105,10 @@
dnl find Apache
SVN_FIND_APACHE
+dnl find Ruby
+
+SVN_FIND_RUBY
+
dnl Check for libraries --------------------
dnl AC_CHECK_LIB() calls go here, if we ever need any
@@ -119,8 +125,8 @@
INSTALL_RULES="install-lib install-bin install-include install-docs"
BUILD_RULES="lib bin test"
if test "$svn_lib_berkeley_db" = "yes"; then
- BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE test fs-test"
- INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE install-include install-docs"
+ BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE $BUILD_RUBY_RULE test fs-test"
+ INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE $INSTALL_RUBY_RULE install-include install-docs"
FS_TEST_DEPS="\$(FS_TEST_DEPS)"
FS_TEST_PROGRAMS="\$(FS_TEST_PROGRAMS)"
fi
Re: [PATCH] Add native ruby binding to Subversion distribution
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
Greg Stein <gs...@lyra.org> writes:
> I'd like to know more about why the Ruby interpreter breaks this. If you
> compile and link using -pthread (what APR discovers), then everything should
> be just fine. What is going on with Ruby? Why does it mess up?
>
> We shouldn't monkey our build system because of a problem with Ruby's
> loading of DSOs. If there is a problem in there, then we should fix it in
> APR, but we can't know more until we have an accurate description of the
> "missing symbol" and the related problems.
Sorry I didn't explain enough. I was in hurry last night.
It's not the problem of Ruby interpreter. Rather, it is the
problem of GCC or the ld. I attached the smallest sample
program apr-pthread-link-test.tar.gz so that you can see
what happens.
The Makefile in sample tar ball build the program called
main which is not compiled with -pthread flag. It also
compiles test.so which calls apr_initialize. It is compiled
and linked with CFLAGS and LDFLAGS from APRVARS. (I copied
the values in my system. You might need to change them.)
That is what is happening with Ruby interpreter and Svn.so.
If you run main, you'll see this:
loaded
./main: relocation error: /usr/local/lib/libapr.so.0: undefined symbol: pthread_mutexattr_init
ldd shows:
ldd /usr/local/lib/libapr.so.0.0.0
libc.so.6 => /lib/libc.so.6 (0x40028000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
ldd test.so
libapr.so.0 => /usr/local/lib/libapr.so.0 (0x4000f000)
libm.so.6 => /lib/libm.so.6 (0x4002a000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4004c000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4007a000)
libdl.so.2 => /lib/libdl.so.2 (0x4008f000)
libc.so.6 => /lib/libc.so.6 (0x40093000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Looking at this, it's natural that loader cannot find
pthread library because it isn't mentioned anywhere.
So why Apache HTTP server runs fine? Because they are
compiled with -pthread flag. If the loader of DSO does not
compiled with -pthread, the problem happens like this. This
doesn't happen if APR is linked with -lpthread.
> > 3. If I reverse the order of CFLAGS and LDFLAGS checking,
> > APR correctly picks up -lpthread and Ruby binding are
> > happy without LDFLAGS kludge.
> The order that APR checks them is correct, as far as I know. Patching it to
> do #3 is simply futzing around with the order to get it to the state you
> want. That doesn't mean that the "desired state" is correct.
Yes, the current order is correct. However, gcc does some
magical thing with -pthread flag which causes the problem.
I don't know if it is gcc's fault or not. I couldn't find
-pthread option in gcc info.
> > LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -rpath $(libdir)
> > +MODULE = $(LIBTOOL) $(LTFLAGS) $(LT_LDFLAGS) $(COMPILE) -module -avoid-version $(LDFLAGS) -rpath $(libdir)
>
> Let's call this LINK_DSO rather than MODULE. The latter doesn't describe the
> operation that is occurring.
OK.
> We might be able to use this for the Apache module, too. I need to learn
> more about the -module switch to see what that does to the output, compared
> to what we do now.
With -module flag, libtool does not require DSO to be
prefixed with lib. In Ruby, DSO named foo.so is loaded by
require 'foo
so I don't want svn.so to be named libsvn.so.
> >...
> > @@ -303,6 +316,10 @@
> > install = 'lib'
> > elif type == 'doc':
> > pass
> > + elif type == 'dso':
> > + ignore, tname = string.split(name, '_')
> > + tfile = tname + '.la'
> > + self.objext = '.lo'
>
> It would be good to have a comment in here on what is happening.
> Specifically, that you're converting "ruby_svn" into "svn". Also, I think
> you should use string.index() rather than split(). That would allow for
> modules like "mod_dav_svn" which have more than underscore.
Will do.
> >...
> > +++ ./build.conf Mon Oct 29 21:10:56 2001
> > @@ -145,6 +145,14 @@
> > # there are some .c files included by others, so *.c isn't appropriate
> > sources = hashtable.c xmlparse.c xmlrole.c xmltok.c
> >
> > +[Ruby_Svn]
>
> Let's keep this all lower-case, like the other targets.
Svn part is to name DSO Svn.so instead of svn.so. But I'll
change it anyway. I'm not attached to the name.
> >...
> > dnl Check for libtool -- we'll definitely need it for all our shared libs!
> > echo "configuring libtool now"
> > +AC_LIBTOOL_DLOPEN
>
> Do we really need this? And the -module flag? It is interesting to note that
> mod_dav_svn has been working quite fine for a long while, without the need
> for this. Apache dlopen's it all the time.
We need -module flag with the reason stated above. And I
needed AC_LIBTOOL_DLOPEN or libtool didn't accept -module
option.
> >...
> > +AC_SUBST(LDFLAGS)
>
> We need to watch out here, as I mentioned before.
Yeah, this will be removed when we resolved -lpthread issue.
Thanks for reviewing the patch.
Re: [PATCH] Add native ruby binding to Subversion distribution
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Oct 29, 2001 at 11:41:17PM +0900, Yoshiki Hayashi wrote:
>...
> to ask. This patch adds -lpthread to LDFLAG if APR is
> compiled with pthread. The problem is, if you load Svn.so
> linked without -lpthread option, Ruby interpreter cannot
> find libpthread and stop execution saying missing symbol or
> something.
I'd like to know more about why the Ruby interpreter breaks this. If you
compile and link using -pthread (what APR discovers), then everything should
be just fine. What is going on with Ruby? Why does it mess up?
We shouldn't monkey our build system because of a problem with Ruby's
loading of DSOs. If there is a problem in there, then we should fix it in
APR, but we can't know more until we have an accurate description of the
"missing symbol" and the related problems.
> Greg said -lpthread should be picked up by APR and I thought
> so but it is not. The problem is the way APR checks CFLAGS
> to gcc and LDFLAGS. First, APR tries to add one of
> following CFLAGS will be necessary to build pthread support.
> -kthread -pthread -pthreads -mthreads -Kthread -threads -mt
>
> Second, it tries to add -lpthread -lpthreads -lc_r to
> LDFLAGS if first step failed.
>
> Here's how it works on my system (Debian unstable):
>
> 1. APR picks up -pthread as CFLAGS. It allows you to
> compile and link pthread programs.
>
> 2. If I enable second check regardless of the result of
> first check, -lpthread will not be added to LDFLAGS
> because -pthread CFLAGS is all you need.
>
> 3. If I reverse the order of CFLAGS and LDFLAGS checking,
> APR correctly picks up -lpthread and Ruby binding are
> happy without LDFLAGS kludge.
>
> It looks like I should post patch to dev@apr to do #3. I
> don't know if it will bring any portability problem but APR
> people can probably figure it out. Anyway, I must go now.
> The time of the last train is approaching. ;-)
The order that APR checks them is correct, as far as I know. Patching it to
do #3 is simply futzing around with the order to get it to the state you
want. That doesn't mean that the "desired state" is correct.
>...
> +++ ./Makefile.in Mon Oct 29 21:08:56 2001
> @@ -53,18 +53,23 @@
> APACHE_INCLUDES = @APACHE_INCLUDES@
> APACHE_TARGET = @APACHE_TARGET@
>
> +RUBY_INCLUDES = @RUBY_INCLUDES@
> +ruby_moddir = @ruby_moddir@
> +
> MKDIR = @MKDIR@
>
> CFLAGS = @CFLAGS@
> CPPFLAGS = @CPPFLAGS@
> -LDFLAGS =
> +LDFLAGS = @LDFLAGS@
>
> COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES)
> LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) -o $@ -c $<
>
> COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c $<
> +COMPILE_RUBY_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(RUBY_INCLUDES) $(INCLUDES) -o $@ -c $<
>
> LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -rpath $(libdir)
> +MODULE = $(LIBTOOL) $(LTFLAGS) $(LT_LDFLAGS) $(COMPILE) -module -avoid-version $(LDFLAGS) -rpath $(libdir)
Let's call this LINK_DSO rather than MODULE. The latter doesn't describe the
operation that is occurring.
We might be able to use this for the Apache module, too. I need to learn
more about the -module switch to see what that does to the output, compared
to what we do now.
>...
> @@ -303,6 +316,10 @@
> install = 'lib'
> elif type == 'doc':
> pass
> + elif type == 'dso':
> + ignore, tname = string.split(name, '_')
> + tfile = tname + '.la'
> + self.objext = '.lo'
It would be good to have a comment in here on what is happening.
Specifically, that you're converting "ruby_svn" into "svn". Also, I think
you should use string.index() rather than split(). That would allow for
modules like "mod_dav_svn" which have more than underscore.
>...
> +++ ./build.conf Mon Oct 29 21:10:56 2001
> @@ -145,6 +145,14 @@
> # there are some .c files included by others, so *.c isn't appropriate
> sources = hashtable.c xmlparse.c xmlrole.c xmltok.c
>
> +[Ruby_Svn]
Let's keep this all lower-case, like the other targets.
>...
> dnl Check for libtool -- we'll definitely need it for all our shared libs!
> echo "configuring libtool now"
> +AC_LIBTOOL_DLOPEN
Do we really need this? And the -module flag? It is interesting to note that
mod_dav_svn has been working quite fine for a long while, without the need
for this. Apache dlopen's it all the time.
>...
> +AC_SUBST(LDFLAGS)
We need to watch out here, as I mentioned before.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add native ruby binding to Subversion distribution
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
Here's the new version of build system patch. The basic
idea is the same as my previous patch so the explanation is
included mostly as is. Please read bindings/ruby/native as
bindings/ruby.
I asked about LDFLAG kludge to Greg Stein on IRC but today
IRC server is flaky and couldn't ask the question I wanted
to ask. This patch adds -lpthread to LDFLAG if APR is
compiled with pthread. The problem is, if you load Svn.so
linked without -lpthread option, Ruby interpreter cannot
find libpthread and stop execution saying missing symbol or
something.
Greg said -lpthread should be picked up by APR and I thought
so but it is not. The problem is the way APR checks CFLAGS
to gcc and LDFLAGS. First, APR tries to add one of
following CFLAGS will be necessary to build pthread support.
-kthread -pthread -pthreads -mthreads -Kthread -threads -mt
Second, it tries to add -lpthread -lpthreads -lc_r to
LDFLAGS if first step failed.
Here's how it works on my system (Debian unstable):
1. APR picks up -pthread as CFLAGS. It allows you to
compile and link pthread programs.
2. If I enable second check regardless of the result of
first check, -lpthread will not be added to LDFLAGS
because -pthread CFLAGS is all you need.
3. If I reverse the order of CFLAGS and LDFLAGS checking,
APR correctly picks up -lpthread and Ruby binding are
happy without LDFLAGS kludge.
It looks like I should post patch to dev@apr to do #3. I
don't know if it will bring any portability problem but APR
people can probably figure it out. Anyway, I must go now.
The time of the last train is approaching. ;-)
Yoshiki Hayashi <yo...@xemacs.org> writes:
> Here's a patch to build native Ruby binding inside
> Subversion distribution. All you have to do is:
> 2. Apply following patch.
>
> 3. Add attached rb-config.rb and svn-ruby.m4 files to
> ac-helpers directory.
>
> The default is not to build Ruby binding so you need to add
> --enable-ruby-binding to configure. The reason is I'm not
> sure it can be built on every system. I can only test it on
> Debian unstable. However, it would be very nice if it can
> be added to Subversion distribution and people can test it
> so that I can shake out some bugs. I expect the default to
> be --enable-ruby-binding in the future.
>
> It installs Svn.la to
> /usr/local/lib/site_ruby/1.6/i386-linux on my machine.
> Probably Debian package or other package on FHS compliant
> system doesn't like it but I decided to ignore it at this
> point.
>
> What this patch does is to add dso type to gen-make.py and
> build.conf. The main purpose is to add new link rule and to
> be able to add more targets which creates Svn.la. The name
> of dso rule consists of language name and .la name
> concatenated with underscore like Ruby_Svn. This allows you
> to add Python_Svn to create another Svn.la at the later time.
>
> There's one problem with this patch, though. It adds hack
> in SVN_FIND_RUBY to add -lpthread to LDFLAGS if -pthread is
> present in CFLAGS. You can link without -lpthread but if
> you try to load the Svn.so from Ruby interpreter, it barfs
> on error that it cannot find libpthread.so. If
> ruby/native/Svn.so is linked with -lpthread, it will be
> loaded successfully. I don't know the correct answer to
> this problem. I thought APR should add -lpthread but the
> magical undocumented -pthread flag of GCC allows you to
> compile and link C programs without problem. The linking
> problem only occurs when a library linked with thread
> enabled APR is dlopened by the program not linked with
> pthread. Any ideas?
>
> I appreciate any feedback.
>
> ChangeLog and patch are attached below.
>
> Makefile.in
>
> (RUBY_INCLUDES, ruby_moddir): New var.
> (LDFLAGS): Now the value is determined by configure.
> (COMPILE_RUBY_MOD, MODULE): New var.
> (INSTAL_RUBY_MOD, RUBY): New var.
>
> gen-make.py
>
> * Use $(MODULE) to link when target type is dso.
> * Add new 'ruby-mod' custom rule to compile Ruby module.
> * Add new target type dso. It is similar to lib but has
> different target name convention and link command.
>
> build.conf
>
> * New target Ruby_Svn.
>
> configure.in
>
> * Include new helper macro from svn-ruby.m4
> * Call AC_LIBTOOL_DLOPEN to check whether the system
> supports dlopen.
> * Call SVN_FIND_RUBY to determine if it can/should build
> Ruby binding.
> * (BUILD_RULES, INSTALL_RULES): Add Ruby rule when
> Berkeley DB is present. Fs binding depends on it.
>
> svn-ruby.m4
>
> New file.
>
> (SVN_FIND_RUBY): New function. If --enable-ruby-binding is
> given and correct inperter is found, add rules to build
> and install Ruby binding.
>
> rb-config.m4
>
> New file.
>
> Return the location of header file or install directory
> depending on the command line argument.
Index: ./Makefile.in
===================================================================
--- ./.svn/text-base/Makefile.in Mon Oct 29 20:13:52 2001
+++ ./Makefile.in Mon Oct 29 21:08:56 2001
@@ -53,18 +53,23 @@
APACHE_INCLUDES = @APACHE_INCLUDES@
APACHE_TARGET = @APACHE_TARGET@
+RUBY_INCLUDES = @RUBY_INCLUDES@
+ruby_moddir = @ruby_moddir@
+
MKDIR = @MKDIR@
CFLAGS = @CFLAGS@
CPPFLAGS = @CPPFLAGS@
-LDFLAGS =
+LDFLAGS = @LDFLAGS@
COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES)
LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) -o $@ -c $<
COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c $<
+COMPILE_RUBY_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(RUBY_INCLUDES) $(INCLUDES) -o $@ -c $<
LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -rpath $(libdir)
+MODULE = $(LIBTOOL) $(LTFLAGS) $(LT_LDFLAGS) $(COMPILE) -module -avoid-version $(LDFLAGS) -rpath $(libdir)
INSTALL = @INSTALL@
INSTALL_LIB = $(LIBTOOL) --mode=install $(INSTALL)
@@ -74,8 +79,10 @@
INSTALL_INCLUDE = $(INSTALL) -m 644
INSTALL_MOD_SHARED = @APXS@ -i -a
INSTALL_MOD_STATIC = $(INSTALL) -m 644
+INSTALL_RUBY_MOD = $(INSTALL_LIB)
PYTHON = @PYTHON@
+RUBY = @RUBY@
all: external-all local-all
clean: external-clean local-clean
Index: ./gen-make.py
===================================================================
--- ./.svn/text-base/gen-make.py Mon Oct 8 17:55:01 2001
+++ ./gen-make.py Mon Oct 29 21:09:19 2001
@@ -115,6 +115,11 @@
# something we don't know, so just include it directly
libs.append(lib)
+ if parser.get(target, 'type') == 'dso':
+ link = '$(MODULE)'
+ else:
+ link = '$(LINK)'
+
targ_varname = string.replace(target, '-', '_')
ldflags = parser.get(target, 'link-flags')
add_deps = parser.get(target, 'add-deps')
@@ -122,11 +127,11 @@
ofile.write('%s_DEPS = %s %s\n'
'%s_OBJECTS = %s\n'
'%s: $(%s_DEPS)\n'
- '\tcd %s && $(LINK) -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
+ '\tcd %s && %s -o %s %s $(%s_OBJECTS) %s $(LIBS)\n\n'
% (targ_varname, string.join(objects + deps), add_deps,
targ_varname, objnames,
tpath, targ_varname,
- path, tfile, ldflags, targ_varname, string.join(libs)))
+ path, link, tfile, ldflags, targ_varname, string.join(libs)))
custom = parser.get(target, 'custom')
if custom == 'apache-mod':
@@ -137,6 +142,14 @@
ofile.write('%s%s: %s\n\t$(COMPILE_APACHE_MOD)\n'
% (src[:-2], objext, src))
ofile.write('\n')
+ elif custom == 'ruby-mod':
+ # special build, needing Ruby includes
+ ofile.write('# build these special -- use RUBY_INCLUDES\n')
+ for src in sources:
+ if src[-2:] == '.c':
+ ofile.write('%s%s: %s\n\t$(COMPILE_RUBY_MOD)\n'
+ % (src[:-2], objext, src))
+ ofile.write('\n')
for g_name, g_targets in install.items():
target_names = [ ]
@@ -303,6 +316,10 @@
install = 'lib'
elif type == 'doc':
pass
+ elif type == 'dso':
+ ignore, tname = string.split(name, '_')
+ tfile = tname + '.la'
+ self.objext = '.lo'
else:
raise GenMakeError('ERROR: unknown build type: ' + type)
@@ -325,6 +342,7 @@
_default_sources = {
'lib' : '*.c',
'exe' : '*.c',
+ 'dso' : '*.c',
'doc' : '*.texi',
}
Index: ./build.conf
===================================================================
--- ./.svn/text-base/build.conf Mon Oct 29 20:13:52 2001
+++ ./build.conf Mon Oct 29 21:10:56 2001
@@ -145,6 +145,14 @@
# there are some .c files included by others, so *.c isn't appropriate
sources = hashtable.c xmlparse.c xmlrole.c xmltok.c
+[Ruby_Svn]
+type = dso
+path = subversion/bindings/ruby
+libs = libsvn_client libsvn_wc libsvn_ra libsvn_repos libsvn_fs
+ libsvn_delta libsvn_subr $(SVN_APR_LIBS)
+custom = ruby-mod
+install = ruby-mod
+
# ----------------------------------------------------------------------------
#
# TESTING TARGETS
Index: ./configure.in
===================================================================
--- ./.svn/text-base/configure.in Mon Oct 29 20:14:01 2001
+++ ./configure.in Mon Oct 29 21:11:57 2001
@@ -31,6 +31,7 @@
sinclude(ac-helpers/svn-macros.m4)
sinclude(ac-helpers/neon.m4)
sinclude(ac-helpers/apr.m4)
+sinclude(ac-helpers/svn-ruby.m4)
dnl Grab the libtool macros
sinclude(ac-helpers/libtool.m4)
@@ -95,6 +96,7 @@
dnl Check for libtool -- we'll definitely need it for all our shared libs!
echo "configuring libtool now"
+AC_LIBTOOL_DLOPEN
AC_PROG_LIBTOOL
NEON_WANTED=0.17.2
@@ -103,6 +105,12 @@
dnl find Apache
SVN_FIND_APACHE
+dnl find Ruby
+
+SVN_FIND_RUBY
+
+AC_SUBST(LDFLAGS)
+
dnl Check for libraries --------------------
dnl AC_CHECK_LIB() calls go here, if we ever need any
@@ -119,8 +127,8 @@
INSTALL_RULES="install-lib install-bin install-include"
BUILD_RULES="lib bin test"
if test "$svn_lib_berkeley_db" = "yes"; then
- BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE test fs-test"
- INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE install-include"
+ BUILD_RULES="lib fs-lib bin fs-bin $BUILD_APACHE_RULE $BUILD_RUBY_RULE test fs-test"
+ INSTALL_RULES="install-lib install-fs-lib install-bin install-fs-bin $INSTALL_APACHE_RULE $INSTALL_RUBY_RULE install-include"
FS_TEST_DEPS="\$(FS_TEST_DEPS)"
FS_TEST_PROGRAMS="\$(FS_TEST_PROGRAMS)"
fi
Re: [PATCH] Add native ruby binding to Subversion distribution
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
Yoshiki Hayashi <yo...@xemacs.org> writes:
> http://www.sodan.org/~penny/tmp/svn-ruby-0.2.tar.gz
That version doesn't compile anymore due to the latest
interface changes. I put the new version (just a snapshot
of my working copy) at
http://www.sodan.org/~penny/tmp/svn-ruby-0.3.tar.gz
--
Yoshiki Hayashi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org