C++ support

[japaric]

@dflemstr I tested (i.e. cross build) this against your vcdiff crate. It worked for x86_64 but failed for armv7 with this error:

running: "arm-linux-gnueabihf-g++" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-fPIC" "-march=armv7-a" "-I" "open-vcdiff/src" "-I" "src" "-Wno-deprecated-declarations" "-DHAVE_EXT_ROPE=1" "-DHAVE_MALLOC_H=1" "-DHAVE_SYS_MMAN_H=1" "-DHAVE_SYS_STAT_H=1" "-DHAVE_SYS_TIME_H=1" "-DHAVE_UNISTD_H=1" "-o" "/target/armv7-unknown-linux-gnueabihf/debug/build/open-vcdiff-sys-92ed9c97abc8a6c4/out/open-vcdiff/src/encodetable.o" "-c" "open-vcdiff/src/encodetable.cc"
cargo:warning=In file included from open-vcdiff/src/google/encodetable.h:23:0,
cargo:warning=                 from open-vcdiff/src/encodetable.cc:20:
cargo:warning=open-vcdiff/src/checksum.h:22:18: fatal error: zlib.h: No such file or directory
cargo:warning=compilation terminated.
ExitStatus(ExitStatus(256))

Installing the zlibg1-dev package, which install /usr/include/zlib.h, "fixes" the problem but that seems like a bug since you already have zlib.h in your vcdiff-sys crate. If you could fix that or point me to another self-contained crate that build C++ code then I could add some tests and add C++ support for other targets.

[homunkulus]

☔ The latest upstream changes (presumably 795a1eb) made this pull request unmergeable. Please resolve the merge conflicts.

[japaric]

@homunkulus r+

[homunkulus]

📋 Looks like this PR is still in progress, ignoring approval

[japaric]

Changed the test crate to a crate that has no system dependencies.

[japaric]

@homunkulus r+

[homunkulus]

📋 Looks like this PR is still in progress, ignoring approval

[japaric]

@homunkulus r+

[homunkulus]

📌 Commit 93124c8 has been approved by japaric

[homunkulus]

⌛ Testing commit 93124c8 with merge 6111835...

[dflemstr]

@japaric sorry, missed your @dflemstr mention. I fixed the crate now by adding an include flag (didn't test it with this branch of cross though so it might still fail)

[dflemstr]

This looks really great by the way, thanks for the efforts!

There's probably some quirks with code that uses global initializers, maybe that isn't triggered by open-vcdiff-sys after all... When I compiled v8 I had to add this: https://github.com/dflemstr/rq/blob/master/ci#L117-L148

Basically, crtbegin.o and crtend.o had to be injected into the linker line. Maybe that's not necessary with this configuration... Also, rustc ships with its own versions of some .o files for some reason which caused more conflicts. But I'll do some tests and see if it is a problem.

[homunkulus]

💔 Test failed - status-travis

[japaric]

@homunkulus r+

[homunkulus]

📌 Commit acbc9e9 has been approved by japaric

[homunkulus]

⌛ Testing commit acbc9e9 with merge 2e1510a...

[japaric]

@dflemstr Are those comments specifically about x86(_64)-musl? I know that those musl targets pass -nostdlib to the linker so that may be why crtbegin.o are not being implicitly linked by the linker.

Also, rustc ships with its own versions of some .o files for some reason

That's also x86(_64)-musl specific. It's done that way so one is able to build binaries statically linked to musl without having to install the musl libc (or musl-gcc).

[homunkulus]

☀️ Test successful - status-travis
Approved by: japaric
Pushing 2e1510a to master...