[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Add native ruby binding to Subversion distribution

From: Yoshiki Hayashi <yoshiki_at_xemacs.org>
Date: 2001-10-30 08:56:34 CET

Greg Stein <gstein@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

Received on Sat Oct 21 14:36:46 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.