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

RE: RE: Post for 32-bit SWIG help for Subversion

From: Prystash,John <prystasj_at_oclc.org>
Date: 2007-06-22 22:09:24 CEST

Turns out the make for the bindings was only building the so for the
Core module. By making the others individually I was able to get around
this

For example:

make -f Makefile.client install

-----Original Message-----
From: Prystash,John [mailto:prystasj@oclc.org]
Sent: Thursday, June 21, 2007 4:53 PM
To: Daniel Rall
Cc: dev@subversion.tigris.org
Subject: RE: Post for 32-bit SWIG help for Subversion

Actually there is a --without-gssapi option in the neon configure and
got past the original make test error. Now I'm seeing a new error which
suggests progress to say the least

# Failed test 'use SVN::Repos;'
# at ../../../../../subversion/bindings/swig/perl/native/t/0use.t line
6.
# Tried to use 'SVN::Repos'.
# Error: Can't load
'/sq/svn/i386/perl/lib/auto/SVN/_Repos/_Repos.so' for module
SVN::_Repos: /sq/svn/i386/perl/lib/auto/SVN/_Repos/_Repos.so: undefined
symbol: Perl_croak_nocontext at /sq/svn/i386/perl/lib/DynaLoader.pm line
230.

This is likely not an architecture issue as much as what is and what is
not on the hosts.

I proceeded with a make install to see what I could and could not use as
before I could use SVN::Base but nothing else. I can now use SVN::Core
without any complaints.

A couple of the modules that use them how similar problems, with
different undefined symbols

perl /sq/svn/i386/lib/SVN/Repos.pm
Can't load '/sq/svn/i386/lib/auto/SVN/_Repos/_Repos.so' for module
SVN::_Repos: /sq/svn/i386/lib/auto/SVN/_Repos/_Repos.so: undefined
symbol: svn_swig_pl_thunk_commit_callback at
/sq/svn/i386/perl/lib/DynaLoader.pm line 230.

perl /sq/svn/i386/lib/SVN/Client.pm
Can't load '/sq/svn/i386/lib/auto/SVN/_Wc/_Wc.so' for module SVN::_Wc:
/sq/svn/i386/lib/auto/SVN/_Wc/_Wc.so: undefined symbol:
svn_swig_pl_status_func at /sq/svn/i386/perl/lib/DynaLoader.pm line 230.

So it looks like Im missing something else

This link described the errors pretty well (although its for BSD), but
the reason for the fix does not apply as I have -lsvn_swig_perl-1 in
LIBS in Makefile.PL.in.

http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2005-October/07012
3.html

-----Original Message-----
From: Daniel Rall [mailto:dlr@collab.net]
Sent: Thursday, June 21, 2007 4:28 PM
To: Prystash,John
Cc: dev@subversion.tigris.org
Subject: Re: Post for 32-bit SWIG help for Subversion

On Thu, 21 Jun 2007, Prystash,John wrote:

> > Is "gssapi/gssapi.h" available on your system? If so, are the
> corresponding libraries in a place where Perl's
> > DynaLoader.pm will pick them up?
>
> I was able to find gssapi headers on the host but no corresponding
> libraries
>
> /usr/kerberos/include/gssapi/gssapi_generic.h
> /usr/kerberos/include/gssapi/gssapi.h
> /usr/kerberos/include/gssapi/gssapi_krb5.h
>
> On the 64-bit host (actually several hosts around here) where this
> works, I found these libraries (no .h's though)
>
> /usr/lib64/libgssapi.so.1
> /usr/lib64/libgssapi.la
> /usr/lib64/libgssapi_krb5.so.2.2
> /usr/lib64/libgssapi_krb5.so.2
> /usr/lib64/libgssapi.so.1.0.0

Neon might not build with HAVE_GSSAPI defined on these systems (an
autoconf test likely fails to define HAVE_GSSAPI before the C compiler
is invoked).

> So it looks like I'm missing the gssapi libraries then? Or can I
> undefine HAVE_GSSAPI?

It's surprising that the headers would be present with the libraries
missing (perhaps they're hiding in a non-standard place?).

If you can smuggle an undef of HAVE_GSSAPI into Neon's build, that might
disable the portion of Neon that's causing you problems.

---------------------------------------------------------------------
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
Received on Fri Jun 22 22:09:19 2007

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.