<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 10, 2013 at 5:39 AM, Peter von Kaehne <span dir="ltr">&lt;<a href="mailto:refdoc@gmx.net" target="_blank">refdoc@gmx.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Greg,<br>
<br>
Von: &quot;Greg Hellings&quot; &lt;<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>&gt;<br>
<div class="im"><br>
On Jun 9, 2013 4:28 PM, &quot;Troy A. Griffitts&quot; &lt;<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>&gt; wrote:<br>
</div><div class="im">&gt;&gt; Do all the bindings build ok?  It sounded like Peter still had some troubles.<br>
&gt;<br>
&gt; 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<br>
&gt; Ubuntu user?) thing. I have not heard other failure reports but the Swig bindings are not regularly built by most people.<br>
<br>
</div>Thanks, this would be appreciated.<br>
<br>
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.<br>

<br>
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 problem.<br>
</blockquote><div><br></div><div style>Strange that we haven&#39;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 &quot;-lstdc++&quot; inside of the existing list. If your issue is a missing link to libstdc++ that might solve the issue.</div>
<div style><br></div><div style>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 &#39;sudo ldconfig&#39;.</div>
<div style><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div><br></div><div style>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 &quot;make clean &amp;&amp; make&quot;. I have not been able to track down the source of the loop yet. Alternatively, if you&#39;re testing with those shell scripts you can just &quot;rm -rf build &amp;&amp; ./cmake/build-debug.sh&quot; and they will recreate the build/ directory. CMake does not like reconfiguring existing build directories, so that is the recommended approach when testing builds.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>--Greg</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Using cmake along the wiki description - i.e. from scratch instead of using the build scripts, I am unable to build too.<br>
<br>
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<br>
<span class="HOEnZb"><font color="#888888"><br>
Peter<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page</div></div></blockquote></div><br></div></div>