On 6/22/07, Prystash,John <prystasj@oclc.org> wrote:
>
>
> 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
I think the issue here was that you ran 'make swig-pl-lib' instead of 'make
swig-pl'. That's why the bindings only built the .so file
HTH,
David
-----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:33:36 2007