[sword-devel] Perl Bindings (was: I implore you...)
greg.hellings at gmail.com
Mon Jun 10 06:15:35 MST 2013
On Mon, Jun 10, 2013 at 5:39 AM, Peter von Kaehne <refdoc at gmx.net> wrote:
> Dear Greg,
> Von: "Greg Hellings" <greg.hellings at gmail.com>
> On Jun 9, 2013 4:28 PM, "Troy A. Griffitts" <scribe at crosswire.org> wrote:
> >> Do all the bindings build ok? It sounded like Peter still had some
> > I can work with him to find the difference between his environment and
> mine and resolve that. The bindings build fine in Fedora 18 just two hours
> ago, so it seems to be an Ubuntu (I believe Peter is an
> > Ubuntu user?) thing. I have not heard other failure reports but the Swig
> bindings are not regularly built by most people.
> Thanks, this would be appreciated.
> I would tend to agree that it might be a problem of my environment +/- my
> level of (in)competence. Having said this, I never remember so many
> difficulties when it is solely my fault for missing/messing something. I
> usually come to a point where I slap my forehead and all works.
> FWIW, a clean checkout of sword from svn builds fine with autotools for
> me. The perl bindings build without error (autotools), but throw a strop
> when loaded in a perl script (as before). The strop appears to mean that a
> c++ environment (libstdc++) does not link in successfully - acc googling
> the error message. Looking at the final automake scripts, I would expect
> that libstdc++ is somewhere mentioned, but it is not. As the automake
> scripts appear to be build by machine in a multistage process I am not
> entirely sure where to look for the origin of the problem. If this is the
Strange that we haven't needed to explicitly link in libstdc++ in the past.
You can try adding, on line 27 of bindings/swig/perl/CMakeLists.txt and
additional "-lstdc++" inside of the existing list. If your issue is a
missing link to libstdc++ that might solve the issue.
Alternatively, if you are installing to a default location other than /usr/
you need to make sure that location is listed in your /etc/ld.so.conf files
and that you run 'sudo ldconfig'.
I was getting an error from the Perl bindings similar to yours that was a
result of installing the libraries to /usr/local/lib instead of /usr/lib
and I resolved it by adding /usr/local/lib to my
/etc/ld.so.conf.d/local.conf file and re-running ldconfig as root.
> Using the cmake build-relase.sh script I am getting a infinite loop at
> around the 97% mark. Am not at home to give the exact error message. The
> build-debug script gives another error message. I will forward exact
> problems later today.
The infinite loop will happen if you try to issue the cmake command from
within an already-built directory without significant changes. I see it all
the time - the easiest way to solve it is just to do "make clean && make".
I have not been able to track down the source of the loop yet.
Alternatively, if you're testing with those shell scripts you can just "rm
-rf build && ./cmake/build-debug.sh" and they will recreate the build/
directory. CMake does not like reconfiguring existing build directories, so
that is the recommended approach when testing builds.
Both of those scripts will configure for installation to locations other
than /usr so you will need the ld.so.conf update if you actually install
those builds. The release targets /opt/sword while the debug targets ~/ by
default. But none of that should affect your ability to actually compile.
> Using cmake along the wiki description - i.e. from scratch instead of
> using the build scripts, I am unable to build too.
> I am not too bothered if the bindings do not make the release in working
> form for me, as long as I get them working at some stage again. I do need
> them for module making
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sword-devel