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
# 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
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
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.
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.
From: Daniel Rall [mailto:email@example.com]
Sent: Thursday, June 21, 2007 4:28 PM
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
> On the 64-bit host (actually several hosts around here) where this
> works, I found these libraries (no .h's though)
Neon might not build with HAVE_GSSAPI defined on these systems (an
autoconf test likely fails to define HAVE_GSSAPI before the C compiler
> 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jun 21 22:53:06 2007