I had installed the bindings successfully without running `make swig-pl'
and only running `make swig-pl-lib' per the install instructions, but
maybe I am reading them wrong. I was trying to install them to a
particular place passing PREFIX to Makefile.PL.
If you need to pass extra parameters to Perl build process
(Makefile.PL),
then you need to do this process somewhat different:
1. Run `make swig-pl-lib' from the top of the Subversion source
tree.
________________________________
From: james82@gmail.com [mailto:james82@gmail.com] On Behalf Of David
James
Sent: Friday, June 22, 2007 4:34 PM
To: Prystash,John
Cc: Daniel Rall; dev@subversion.tigris.org
Subject: Re: RE: Post for 32-bit SWIG help for Subversion
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 Mon Jun 25 15:06:26 2007