dynamic-link and load-extension work without passing the .so or .dll as
the shared library extension, so these have been dropped so the examples
and test-suite work on Cygwin.
Also update documentation and use the 'lib' prefix as that is what we
commonly name the shared libraries.
Replace pkg-config with guile-config to look for guile. Using pkg-config
requires the pkg.m4 autoconf macros to be properly installed on the
machine running autogen.sh which is frequently a problem. pkg-config
only supports more recent releases of guile so isn't very good at
finding guile either.
'make check' does not require the Python static libraries to be
available. There is no easy way to find PYLIB - the directory containing
the static library especially now Debian based systems have changed to
put them in directories like /usr/lib/x86_64-linux-gnu/libpython2.7.a.
On 19/04/13 18:41, Geert Janssens wrote:
> Hi,
>
> I'm working through the failing testcases for guile. One testcase fails
> with a compilation error in some generated code based on std_map and
> std_pair. I know exactly where this generated code comes from, but my
> C++ knowledge is insufficient to understand the error, let alone remedy
> it. I gather some kind of const violation, but that's all I can read
> from it :( My hope is that someone used to working with stl will more
> easily understand it.
>
> So, if someone can help me understand the error and what the fix would
> be in C++, I can fix the corresponding .i file.
>
> This is the code snippet the causes the error:
>
<snip>
>
> /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:88:12:
> error: non-static const member ‘const std::pair<int, A*> std::pair<int,
> const std::pair<int, A*> >::second’, can’t use default assignment operator
This is the main problem - it is saying there is no default assignment
operator (because one of the members in pair is const). The solution is
to avoid assignment. I've attached a patch to do this plus some error
message corrections.
William
All of guile's interface files now use the scm interface.
This should not affect any users. Swig generated code
using the scm interface can be mixed with gh interface
using user code.
It does simplify maintenance of the guile swig code though.
Note: guile-config is badly broken for guile 2. So
the guile configure section has been rewritten to
use pkg-config instead.
Manually resolved conflicts:
Examples/Makefile.in
It is failing in Travis builds with 'ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-linux]' but okay with 'ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]'.
Relying on timely Garbage collection is probably flawed anyway.
