Cap'n Proto Lite on Linux

[brian...@gmail.com]

I would like to distribute a linux binary for my tool that works on as many distros as possible, and I don't need the RPC or reflection features. Does the Lite version completely remove the c++11 dependency? If so, is there a way to build it on an older Linux? It seems like I need a prebuilt capnp, which is only distributed for Windows.

[Farz Hemmati]

If you statically link the binary against libc++, it doesn't matter if it used c++11 or not. You can run it on any version of Linux that has the other libraries. You might as well statically link everything but libc and you'll be safe.

On Wed, Jan 21, 2015 at 7:50 AM, <brian...@gmail.com> wrote:

I would like to distribute a linux binary for my tool that works on as many distros as possible, and I don't need the RPC or reflection features. Does the Lite version completely remove the c++11 dependency? If so, is there a way to build it on an older Linux? It seems like I need a prebuilt capnp, which is only distributed for Windows.

--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.

[Kenton Varda]

Hi Brian,

All of Cap'n Proto is C++11, including lite mode. In lite mode we've merely managed to avoid a couple features that MSVC hasn't implemented yet.

I'm not sure if I completely understand your question. Are you distributing a binary or source code? If it's a binary, and you want it to work on older Linux distros, you may need to statically link against libstdc++ (but don't statically link glibc -- that causes all sorts of problems). This would be true for any C++ app, C++11 or not. If you are distributing code, your clients will need GCC 4.8 to compile it; there's really no way around that. But it's probably possible to get GCC 4.8 (or Clang) to run on old Linux.

-Kenton

On Wed, Jan 21, 2015 at 7:50 AM, <brian...@gmail.com> wrote:

I would like to distribute a linux binary for my tool that works on as many distros as possible, and I don't need the RPC or reflection features. Does the Lite version completely remove the c++11 dependency? If so, is there a way to build it on an older Linux? It seems like I need a prebuilt capnp, which is only distributed for Windows.

--

[brian...@gmail.com]

I'm distributing a binary, but I was building that binary on older Linux so it doesn't have recent dependencies. I'm now building on CentOS7 to get C++11. Statically linking libstdc++ does provide some compatibility, but there is still a dependency on GLIBC_2.14  that precludes, for example, CentOS6. So I just need to figure out how to build with C++11 while referencing an older GLIBC (if that's possible). I'm sure this is beyond the scope of Cap'n Proto, so I'll try to look into this on my own. Thanks for the help.

[Kenton Varda]

FWIW, I'm also interested in the answer to this question. :)

For Sandstorm.io we've resorted to static linking, which is OK for us since we don't use DNS in the relevant binaries, though arguably we ought to dynamically link at least to get position-independent executables, for the purpose of ASLR.

Meteor ships Node and Mongo binaries that appear to be dynamically-linked. I should ask them about their experience with this.

-Kenton

[brian...@gmail.com]

As long as you're interested, the cause of our GLIBC_2.14 dependency (according to the "nm" command) is memcpy(). Everything else is 2.3.2 or earlier.

[Kenton Varda]

Hmm, that seems odd. memcpy() certainly isn't new. :)

Ah, here's an explanation:

http://www.win.tue.nl/~aeb/linux/misc/gcc-semibug.html

I guess you'll want to include that __asm__ line.

-Kenton

[paul.ba...@googlemail.com]

Reasonable BLOG post on creating portable linux binaries (and figuring out things like GLIBC incompatabilities)

http://insanecoding.blogspot.in/2012/07/creating-portable-linux-binaries.html

[brian...@gmail.com]

Thanks, this helped a lot. The only other problem was that the 2.14 dependency would reappear when we linked in our static libstdc++.a, but we got around that with a memcpy wrapper and the ld --wrap argument, as described here.