When doing streaming deserialization, valgrind complains about mismatched free()...
It's caused by calls to auto_ptr::free for zones that are null pointers.
The patch add serialization operator for the given enum to avoid the use
of a cast which leads to strict-aliasing warnings and the test to fail.
Solution suggested by qehgt.
The exceptions for Rubinius are unnecessary now and are actually
causing msgpack not to install due to the incorrect function prototypes
that are in this file. In MRI, this is the prototype
VALUE rb_gc_enable();
Anyway, these are unnecessary for Rubinius.
About pkg-config:
From http://www.freedesktop.org/wiki/Software/pkg-config
pkg-config is a helper tool used when compiling applications and
libraries. It helps you insert the correct compiler options on the
command line so an application can use gcc -o test test.c
`pkg-config --libs --cflags glib-2.0` for instance, rather than
hard-coding values on where to find glib (or other libraries). It is
language-agnostic, so it can be used for defining the location of
documentation tools, for instance.
pkg-config is a widely used build helper tool. Major build tools such
as GNU Autoconf, CMake and so on support pkg-config.
MessagePack users can build their software more easily.
From what I could investigate, msgpack doesn't modify char* buffers
obtained from RSTRING_PTR. This means that on Rubinius we don't have to
copy back and forth the buffer to make sure it's also updated on the
Ruby side.
This copying of buffers is a similar problem as the RARRAY_PTR problem,
because it is not safe to expose GC'ed memory on Rubinius to extensions
since it can move due to Rubinius having a moving GC.
Using internals of MRI by using RARRAY_PTR makes it necessary for other
implementations such as Rubinius to continuously copy the structure
returned by RARRAY_PTR back and forth since in Rubinius objects are
layed out differently internally.
Extensions should not depend and use these internal MRI structures if
this is not necessary and when there are API methods that can provide
the same functionality. This makes sure other implementations can also
use the extension without any big problems.
For this reason I also removed the FIXME comment, since that change
would also heavily depend on the internal memory layout of objects on
MRI.
libtool requires -no-undefined link option to generate a DLL
by MinGW. A DLL should not have any unresolved symbols and
-no-undefined link option declares that the library doesn't
depends on any libraries other than the ones listed on the
command line.
See also: description about -no-undefined option at
http://www.gnu.org/software/libtool/manual/libtool.html#Link-mode
nori0428