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

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 <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

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~