Patchwork Add msgpack

login
register
mail settings
Submitter Lukas Gradl
Date June 17, 2016, 3:13 p.m.
Message ID <87fusbyhk7.fsf@openmailbox.org>
Download mbox | patch
Permalink /patch/13168/
State New
Headers show

Comments

Lukas Gradl - June 17, 2016, 3:13 p.m.
Hi,

Leo Famulari <leo@famulari.name> writes:

> On Mon, Jun 13, 2016 at 12:58:52PM -0400, Leo Famulari wrote:
>> On Sat, Jun 11, 2016 at 11:24:23PM -0500, Lukas Gradl wrote:
>> > Oh, that is true.  I searched around, but I could not find anything
>> > about zbuffer.h[pp].  I am not sure what it is used for.  FWIW, it is
>> > only referenced in src/Makefile, src/Makefile.in, src/Makefile.am
>> > CMakeLists.txt and in the tests:
>> 
>> [...]
>> 
>> > Judging from this, I am inclined to think that msgpack does not use
>> > these two headers for anything but tests.  But I am not sure about
>> > this.
>> 
>> I think that another application would call the zbuffer functions,
>> although the string 'zbuffer' does not exist in the opendht source code.
>> But, we should make sure msgpack will work for other calling
>> applications that might be added later.

OK, I agree.

>> 
>> On #guix, bavier suggested we patch 'msgpack.pc.in'. Specifically, we
>> should append the include flag to 'Cflags:' and create a 'Libs.private:'
>> field for the -L and -l flags. There are some examples in
>> 'gnu/packages'.
>> 
>> More details on the IRC log:
>> https://gnunet.org/bot/log/guix/2016-06-13#T1056507
>> 
>> I've cc-ed Eric since I don't know much about pkg-config.

Neither do I. 

I have experimented with this a bit.  IIUC, since our zlib provides a
pkg-config file we can generate the the -I flag by adding

---8<--- cut here -------------------- start --->8---
Requires.private: zlib
---8<--- cut here -------------------- end ----->8---

to the msgpack.pc.in file.  This also gives me the -L flag. The -l flag
is only emitted when --static is passed to pkg-config.  I tried to fix
this by adding -lz to Libs.private resulting in:

---8<--- cut here -------------------- start --->8---
lukas@serenity$ guix environment msgpack
lukas@serenity [env]$ cat /gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1/lib/pkgconfig/msgpack.pc 
prefix=/gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: MessagePack
Description: Binary-based efficient object serialization library
Version: 1.4.1
Libs: -L${libdir} -lmsgpackc
Cflags: -I${includedir}
Requires.private: zlib
Libs.private: -lz
lukas@serenity [env]$ pkg-config --libs --cflags /gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1/lib/pkgconfig/msgpack.pc 
-I/gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1/include -I/gnu/store/hsxhfmjgh8m4c0pavq3gd3gcrn8zrgxj-zlib-1.2.8/include -L/gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1/lib -lmsgpackc
lukas@serenity [env]$ pkg-config --libs --cflags --static /gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1/lib/pkgconfig/msgpack.pc 
-I/gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1/include -I/gnu/store/hsxhfmjgh8m4c0pavq3gd3gcrn8zrgxj-zlib-1.2.8/include -L/gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1/lib -L/gnu/store/hsxhfmjgh8m4c0pavq3gd3gcrn8zrgxj-zlib-1.2.8/lib -lmsgpackc -lz
lukas@serenity [env]$ guix gc --references /gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22
/gnu/store/gibnvxf2029gxmmxv8bgqilvlagzzskb-msgpack-1.4.1
/gnu/store/v39bh3ln3ncnzhyw0kd12d46kww9747v-gcc-4.9.3-lib
lukas@serenity [env]$ 
---8<--- cut here -------------------- end ----->8---

So I still only get the -lz flag for static linking.  I am not sure if
this is what we want, what do you think?

Also, still no store refernece. BTW, where is "guix gc --references"
implemented?  I looked for it but failed to find the actual logic, since
I am not that fluent with Scheme...

From this I think that adding the -lz to Libs.private is redundant if
zlib is in "Requires.private".  But if we want -lz also for dynamic
linking then I think we need to move zlib to "Requires".  I went ahead
and tried that leading to this result:

---8<--- cut here -------------------- start --->8---
lukas@serenity$ guix environment msgpack
lukas@serenity [env]$ cat /gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1/lib/pkgconfig/msgpack.pc 
prefix=/gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: MessagePack
Description: Binary-based efficient object serialization library
Version: 1.4.1
Libs: -L${libdir} -lmsgpackc
Cflags: -I${includedir}
Requires: zlib
lukas@serenity [env]$ pkg-config --libs --cflags /gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1/lib/pkgconfig/msgpack.pc 
-I/gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1/include -I/gnu/store/hsxhfmjgh8m4c0pavq3gd3gcrn8zrgxj-zlib-1.2.8/include -L/gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1/lib -L/gnu/store/hsxhfmjgh8m4c0pavq3gd3gcrn8zrgxj-zlib-1.2.8/lib -lmsgpackc -lz
lukas@serenity [env]$ pkg-config --libs --cflags --static /gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1/lib/pkgconfig/msgpack.pc 
-I/gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1/include -I/gnu/store/hsxhfmjgh8m4c0pavq3gd3gcrn8zrgxj-zlib-1.2.8/include -L/gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1/lib -L/gnu/store/hsxhfmjgh8m4c0pavq3gd3gcrn8zrgxj-zlib-1.2.8/lib -lmsgpackc -lz
lukas@serenity [env]$ guix gc --references /gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22
/gnu/store/9ipfx15i5hbkgq26by13d07i47nmbldp-msgpack-1.4.1
/gnu/store/v39bh3ln3ncnzhyw0kd12d46kww9747v-gcc-4.9.3-lib
lukas@serenity [env]$ 
---8<--- cut here -------------------- end ----->8---

So the flags -I, -L, -l for zlib are all there for both dynamic and
static linking.  But still no store reference.

A patch for this last case is attached.

IIUC, zlib has to be a propagated input in this case.  Do you agree with
that?

More general, do you think what I did makes sense?  I am not really sure
if -lz is needed for dynamic linking or not.

Also, is it OK to do things like that in a snippet as in the attached
patch?

Thank you for your help!

Best,
Lukas
Lukas Gradl - June 19, 2016, 3:44 a.m.
Lukas Gradl <lgradl@openmailbox.org> writes:

> So the flags -I, -L, -l for zlib are all there for both dynamic and
> static linking.  But still no store reference.

I think the reason why there is no reference is that msgpack uses
zbuffer only for tests.  Before compilation, the file only references
the name "zlib" and does not mention the hash in the path of zlib in the
store.  During compilation (during "check"), this mere name "zlib" gets
somehow resolved to the path of zlib in the store.  The binary file
resulting from compiling zbuffer should therefore contain a reference to
zlib, which should be detectable by guix gc --references.  I think
however, that this binary file does not get installed as it is only used
for tests.  All the files that do get installed in the output path of
msgpack in the store do not contain the hash part of the store-path of
zlib.  They only refer to zlib by name.  IIUC this can not be detected
by guix gc --references since it only searches for the hash part of
the store-path of zlib.

This is what I grasp from looking at libstore/references.cc and
libstore/store-api.cc.  I am not sure about this though.

Best,
Lukas
Leo Famulari - June 20, 2016, 5:09 p.m.
On Sat, Jun 18, 2016 at 10:44:16PM -0500, Lukas Gradl wrote:
> Lukas Gradl <lgradl@openmailbox.org> writes:
> 
> > So the flags -I, -L, -l for zlib are all there for both dynamic and
> > static linking.  But still no store reference.
> 
> I think the reason why there is no reference is that msgpack uses
> zbuffer only for tests.  Before compilation, the file only references
> the name "zlib" and does not mention the hash in the path of zlib in the
> store.  During compilation (during "check"), this mere name "zlib" gets
> somehow resolved to the path of zlib in the store.  The binary file
> resulting from compiling zbuffer should therefore contain a reference to
> zlib, which should be detectable by guix gc --references.  I think
> however, that this binary file does not get installed as it is only used
> for tests.  All the files that do get installed in the output path of
> msgpack in the store do not contain the hash part of the store-path of
> zlib.  They only refer to zlib by name.  IIUC this can not be detected
> by guix gc --references since it only searches for the hash part of
> the store-path of zlib.
> 
> This is what I grasp from looking at libstore/references.cc and
> libstore/store-api.cc.  I am not sure about this though.

That's my understanding as well.

Thanks for trying all the things you described in your previous email.

Since we are still stuck on this, I think we should continue with Ring
and see if this becomes a problem later on. If so, let's contact the
msgpack maintainers and ask for advice.

We should add a caveat in a comment in msgpack's package definition, for
future readers.

I'm curious — how close are you to a Ring package definition?
Ludovic Courtès - June 21, 2016, 8:38 a.m.
Hello!

Sorry for the late reply, but…

Lukas Gradl <lgradl@openmailbox.org> skribis:

> All the files that do get installed in the output path of
> msgpack in the store do not contain the hash part of the store-path of
> zlib.  They only refer to zlib by name.

What kind of files are these, and how do they refer to zlib exactly?

(I’m curious, but this shouldn’t block the process, as Leo wrote.)

Thanks,
Ludo’.
Lukas Gradl - June 21, 2016, 1:31 p.m.
Hi,

ludo@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Sorry for the late reply, but…
>
> Lukas Gradl <lgradl@openmailbox.org> skribis:
>
>> All the files that do get installed in the output path of
>> msgpack in the store do not contain the hash part of the store-path of
>> zlib.  They only refer to zlib by name.
>
> What kind of files are these, and how do they refer to zlib exactly?
>
> (I’m curious, but this shouldn’t block the process, as Leo wrote.)

It is a C Header file and a corresponding C++ Header file
(include/msgpack/zbuffer.h[pp]).  They refer to zlib by just doing:

#include <zlib.h>

These two files do get installed in the store, but their compiled
counterparts do not.



Thinking out loud, we could possibly force the creation of a reference to
zlib by putting the path of the zlib used when building the package into
a comment or a seperate file.
On the other hand, I am not so sure if we really want a reference, since,
as you said, they are for run-time dependencies.  Since msgpack itself
does not use zbuffer at run-time (only at build time for tests) and does
not provide a library including zbuffer for other packages to link
against, the files zbuffer.h[pp] are really not used at run-time.  The
only time that I can think of when these files could be used is during
the build of a dependent package that wants to include these files.
Propagating zlib would assure that zlib is available whenever
zbuffer.h[pp] gets included by some other package.  Maybe this is the
right way to represent the situation?

Best,
Lukas
Ludovic Courtès - June 21, 2016, 2:11 p.m.
Hello!

Lukas Gradl <lgradl@openmailbox.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hello!
>>
>> Sorry for the late reply, but…
>>
>> Lukas Gradl <lgradl@openmailbox.org> skribis:
>>
>>> All the files that do get installed in the output path of
>>> msgpack in the store do not contain the hash part of the store-path of
>>> zlib.  They only refer to zlib by name.
>>
>> What kind of files are these, and how do they refer to zlib exactly?
>>
>> (I’m curious, but this shouldn’t block the process, as Leo wrote.)
>
> It is a C Header file and a corresponding C++ Header file
> (include/msgpack/zbuffer.h[pp]).  They refer to zlib by just doing:
>
> #include <zlib.h>
>
> These two files do get installed in the store, but their compiled
> counterparts do not.

OK, this is a justification for putting zlib in ‘propagated-inputs’
rather than ‘inputs’ (the manual mentions this as one of the valid
justifications for ‘propagated-inputs’ (info "(guix) package Reference")).
It is worth adding a margin comment with this explanation.

> Thinking out loud, we could possibly force the creation of a reference to
> zlib by putting the path of the zlib used when building the package into
> a comment or a seperate file.
> On the other hand, I am not so sure if we really want a reference, since,
> as you said, they are for run-time dependencies.  Since msgpack itself
> does not use zbuffer at run-time (only at build time for tests) and does
> not provide a library including zbuffer for other packages to link
> against, the files zbuffer.h[pp] are really not used at run-time.  The
> only time that I can think of when these files could be used is during
> the build of a dependent package that wants to include these files.
> Propagating zlib would assure that zlib is available whenever
> zbuffer.h[pp] gets included by some other package.  Maybe this is the
> right way to represent the situation?

It is.  :-)

Thanks for explaining!

Ludo’.
Lukas Gradl - June 21, 2016, 3:59 p.m.
Leo Famulari <leo@famulari.name> writes:

> I'm curious — how close are you to a Ring package definition?


According to
https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php/Build_Instructions,
Ring is divided into three Layers:
 * Libring (or ring-daemon)
 * LibringClient
 * Clints

I have a work-in-progress definition for libring, I have not started
working on the other layers yet.  I will clean up the wip-patches that I
have and send them them later today.

At the moment I am still tracking down (i.e. unbundling) dependencies
for libring.  At the moment I am working on pjptoject which is one of
the "main" dependencies according to this:
https://ring.cx/en/about/technical#Libraries

There are some more dependencies that might be needed, that I noticed
when looking at librings contrib directory.  This inputs field reflects
all the dependencies from libring's contrib:

      (inputs
       `(("ffmpeg" ,ffmpeg)
         ("flac" ,flac)
         ("libgcrypt" ,libgcrypt)
         ("gmp" ,gmp)
        ; ("gnutls" ,gnutls) ; Maybe not needed as already used by inputs
         ("libgpg-error" ,libgpg-error)
        ; ("gsm" ,gsm)  ; not found
         ("libiax2" ,libiax2)
         ("libiconv" ,libiconv)
         ("jack" ,jack-1)
        ; ("json-c" ,json-c) ; not found
        ; ("msgpack" ,msgpack) ; maybe not needed as used by inputs (opendht)
        ; ("nettle" ,nettle) ; maybe not needed (only certain proprietary OSes?)
         ("libogg" ,libogg)
         ("opendht" ,opendht)
         ("opus" ,opus)
         ("pcre" ,pcre)
        ; ("pjproject" ,pjproject-for-libring) ; not found, WIP
        ; ("pkg-static" ,pkg-static) ; not found
         ("portaudio" ,portaudio)
         ("libsamplerate" ,libsamplerate)
         ("libsndfile" ,libsndfile)
         ("speex" ,speex)
        ; ("speexdsp" ,speexdsp)
         ("libupnp" ,libupnp)
        ; ("uuid" ,uuid) ; not found, maybe not needed (only certain proprietary OSes?)
         ("libvorbis" ,libvorbis)
         ("libvpx" ,libvpx)
         ("libx264" ,libx264)
        ; ("yaml-cpp" ,yaml-cpp) ;not found
         ("zlib" ,zlib))) ; maybe not needed as used by inputs


Sorry for the format, I will send a real patch later today.  The ones
that are commented above have some issue that needs to be resolved.

I don't really have a lot of time to work on this so progress has been
slow.  Sorry for that.

As I said I will post two patches later (pjproject & libring).  Any help
on those or some of the missing inputs is of course greatly appreciated!


Sorry for the delay!
Best,
Lukas
Efraim Flashner - June 21, 2016, 4:49 p.m.
On Tue, Jun 21, 2016 at 10:59:06AM -0500, Lukas Gradl wrote:
> Leo Famulari <leo@famulari.name> writes:
> 
> > I'm curious — how close are you to a Ring package definition?
> 
> 
> According to
> https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php/Build_Instructions,
> Ring is divided into three Layers:
>  * Libring (or ring-daemon)
>  * LibringClient
>  * Clints
> 
> I have a work-in-progress definition for libring, I have not started
> working on the other layers yet.  I will clean up the wip-patches that I
> have and send them them later today.
> 
> At the moment I am still tracking down (i.e. unbundling) dependencies
> for libring.  At the moment I am working on pjptoject which is one of
> the "main" dependencies according to this:
> https://ring.cx/en/about/technical#Libraries
> 
> There are some more dependencies that might be needed, that I noticed
> when looking at librings contrib directory.  This inputs field reflects
> all the dependencies from libring's contrib:
> 
>       (inputs
>        `(("ffmpeg" ,ffmpeg)
>          ("flac" ,flac)
>          ("libgcrypt" ,libgcrypt)
>          ("gmp" ,gmp)
>         ; ("gnutls" ,gnutls) ; Maybe not needed as already used by inputs
>          ("libgpg-error" ,libgpg-error)
>         ; ("gsm" ,gsm)  ; not found
>          ("libiax2" ,libiax2)
>          ("libiconv" ,libiconv)
>          ("jack" ,jack-1)
>         ; ("json-c" ,json-c) ; not found

there's a json-c in web.scm

>         ; ("msgpack" ,msgpack) ; maybe not needed as used by inputs (opendht)
>         ; ("nettle" ,nettle) ; maybe not needed (only certain proprietary OSes?)
>          ("libogg" ,libogg)
>          ("opendht" ,opendht)
>          ("opus" ,opus)
>          ("pcre" ,pcre)
>         ; ("pjproject" ,pjproject-for-libring) ; not found, WIP
>         ; ("pkg-static" ,pkg-static) ; not found
>          ("portaudio" ,portaudio)
>          ("libsamplerate" ,libsamplerate)
>          ("libsndfile" ,libsndfile)
>          ("speex" ,speex)
>         ; ("speexdsp" ,speexdsp)
>          ("libupnp" ,libupnp)
>         ; ("uuid" ,uuid) ; not found, maybe not needed (only certain proprietary OSes?)

try util-linux for this one

>          ("libvorbis" ,libvorbis)
>          ("libvpx" ,libvpx)
>          ("libx264" ,libx264)
>         ; ("yaml-cpp" ,yaml-cpp) ;not found

there's a libyaml in web.scm. not exactly yaml-cpp in name, but it might
be close enough

>          ("zlib" ,zlib))) ; maybe not needed as used by inputs
> 
> 
> Sorry for the format, I will send a real patch later today.  The ones
> that are commented above have some issue that needs to be resolved.
> 
> I don't really have a lot of time to work on this so progress has been
> slow.  Sorry for that.
> 
> As I said I will post two patches later (pjproject & libring).  Any help
> on those or some of the missing inputs is of course greatly appreciated!
> 
> 
> Sorry for the delay!
> Best,
> Lukas
> 

keep up the great work!
Lukas Gradl - June 22, 2016, 6:05 a.m.
Thank you for looking at this!

Efraim Flashner <efraim@flashner.co.il> writes:

> On Tue, Jun 21, 2016 at 10:59:06AM -0500, Lukas Gradl wrote:
>> Leo Famulari <leo@famulari.name> writes:
>> 
>> > I'm curious — how close are you to a Ring package definition?

>> 
>> There are some more dependencies that might be needed, that I noticed
>> when looking at librings contrib directory.  This inputs field reflects
>> all the dependencies from libring's contrib:
>> 
>>       (inputs
>>        `(("ffmpeg" ,ffmpeg)
>>          ("flac" ,flac)
>>          ("libgcrypt" ,libgcrypt)
>>          ("gmp" ,gmp)
>>         ; ("gnutls" ,gnutls) ; Maybe not needed as already used by inputs
>>          ("libgpg-error" ,libgpg-error)
>>         ; ("gsm" ,gsm)  ; not found
>>          ("libiax2" ,libiax2)
>>          ("libiconv" ,libiconv)
>>          ("jack" ,jack-1)
>>         ; ("json-c" ,json-c) ; not found
>
> there's a json-c in web.scm

This one is actually a typo and a mistake on my part.  This is supposed
to be jsoncpp.  But I recently changed to the commit tagged with the
latest version number and it seems this is not needed anymore/yet.

>
>>         ; ("msgpack" ,msgpack) ; maybe not needed as used by inputs (opendht)
>>         ; ("nettle" ,nettle) ; maybe not needed (only certain proprietary OSes?)
>>          ("libogg" ,libogg)
>>          ("opendht" ,opendht)
>>          ("opus" ,opus)
>>          ("pcre" ,pcre)
>>         ; ("pjproject" ,pjproject-for-libring) ; not found, WIP
>>         ; ("pkg-static" ,pkg-static) ; not found
>>          ("portaudio" ,portaudio)
>>          ("libsamplerate" ,libsamplerate)
>>          ("libsndfile" ,libsndfile)
>>          ("speex" ,speex)
>>         ; ("speexdsp" ,speexdsp)
>>          ("libupnp" ,libupnp)
>>         ; ("uuid" ,uuid) ; not found, maybe not needed (only certain proprietary OSes?)
>
> try util-linux for this one
>

This looks good on first glance.  I will need to look into this more.
Thank you!

>>          ("libvorbis" ,libvorbis)
>>          ("libvpx" ,libvpx)
>>          ("libx264" ,libx264)
>>         ; ("yaml-cpp" ,yaml-cpp) ;not found
>
> there's a libyaml in web.scm. not exactly yaml-cpp in name, but it might
> be close enough
>

I have not investigated this much yet, but I think these are different.
FWIW, they are mentioned seperately in
https://en.wikipedia.org/wiki/YAML#Implementations
I will have a look at this.


>>          ("zlib" ,zlib))) ; maybe not needed as used by inputs

>> 
>> 
>> 
>
> keep up the great work!

Thank you! And thank you for your help!

Best,
Lukas
Leo Famulari - June 25, 2016, 3:31 p.m.
On Fri, Jun 17, 2016 at 10:13:28AM -0500, Lukas Gradl wrote:
> Also, is it OK to do things like that in a snippet as in the attached
> patch?

> * gnu/packages/serialization.scm (msgpack): New variable.

I think it's fine and I pushed as d1ef573de. If we need to change it for
libring, we'll do that. Thanks!
Lukas Gradl - June 25, 2016, 4:40 p.m.
Leo Famulari <leo@famulari.name> writes:

> On Fri, Jun 17, 2016 at 10:13:28AM -0500, Lukas Gradl wrote:
>> Also, is it OK to do things like that in a snippet as in the attached
>> patch?
>
>> * gnu/packages/serialization.scm (msgpack): New variable.
>
> I think it's fine and I pushed as d1ef573de. If we need to change it for
> libring, we'll do that. Thanks!

OK, Thank you!

Patch

From cfb8a68cb4e18e3a811e7ae96b7df64fceb8c6c5 Mon Sep 17 00:00:00 2001
From: Lukas Gradl <lgradl@openmailbox.org>
Date: Fri, 17 Jun 2016 10:08:48 -0500
Subject: [PATCH] gnu: Add msgpack.

* gnu/packages/serialization.scm (msgpack): New variable.
---
 gnu/packages/serialization.scm | 50 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/serialization.scm b/gnu/packages/serialization.scm
index 8dfd21d..085534d 100644
--- a/gnu/packages/serialization.scm
+++ b/gnu/packages/serialization.scm
@@ -1,5 +1,6 @@ 
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015 Ricardo Wurmus <rekado@elephly.net>
+;;; Copyright © 2016 Lukas Gradl <lgradl@openmailbox.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -21,8 +22,13 @@ 
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system cmake)
+  #:use-module (guix build-system gnu)
   #:use-module (gnu packages)
-  #:use-module (gnu packages documentation))
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages check)
+  #:use-module (gnu packages compression)
+  #:use-module (gnu packages documentation)
+  #:use-module (gnu packages pkg-config))
 
 (define-public cereal
   (package
@@ -72,3 +78,45 @@ 
 arbitrary data types and reversibly turns them into different representations,
 such as compact binary encodings, XML, or JSON.")
     (license license:bsd-3)))
+
+
+(define-public msgpack
+  (package
+    (name "msgpack")
+    (version "1.4.1")
+    (source
+     (origin
+       (method url-fetch)
+       (uri
+        (string-append
+         "https://github.com/msgpack/msgpack-c/releases/download/"
+         "cpp-" version "/msgpack-" version ".tar.gz"))
+       (snippet
+        '(let ((p (open-file "msgpack.pc.in" "a")))
+           (begin
+             (display
+              (string-append "Requires: " "zlib" "\n") p)
+             (close-output-port p))))
+       (sha256
+        (base32
+         "0bpjfh9vz0n2k93mph3x15clmigkgs223xfn8h12ymrh5gsi5ica"))))
+    (build-system gnu-build-system)
+    (native-inputs
+     `(("googletest" ,googletest)
+       ("autoconf" ,autoconf)
+       ("automake" ,automake)
+       ("libtool" ,libtool)
+       ("pkg-config" ,pkg-config)))
+    (propagated-inputs
+     `(("zlib" ,zlib)))
+    (arguments
+     `(#:phases
+       (modify-phases %standard-phases
+         (add-before 'configure 'autoconf
+           (lambda _
+             (system* "autoreconf" "-vfi"))))))
+    (home-page "http://www.msgpack.org")
+    (synopsis "Binary serialization library")
+    (description "Msgpack is a library for C/C++ that implements binary
+serialization.")
+    (license license:boost1.0)))
-- 
2.7.4