relocation R_X86_64_32 against `.rodata' can not be used when making a shared object

[JeanMertz]

Thank you for this crate, and the json-query project.

I've been working with the crate recently, and things are working wonderfully. I'm using the bundled feature of json-query to support statically linking to the required libjq dependency.

This worked on macOS, and also in an "alpine" based container, but I've since pushed my code changes and it seems that Travis is having some issues.

Travis is running the Ubuntu Xenial release and it's throwing the following error:

  = note: /usr/bin/ld: /home/travis/build/blendle/automaat/target/debug/deps/libjq_sys-e398fc3ed0925020.rlib(execute.o):
relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; 
recompile with -fPIC
          /home/travis/build/blendle/automaat/target/debug/deps/libjq_sys-e398fc3ed0925020.rlib: error adding symbols: Bad value
          collect2: error: ld returned 1 exit status

The build is publicly available here.

I've cleared the Travis cache, but the problem did not go away. The compiler is pretty clear with the recompile with -fPIC message, but I'm not quite sure how or where to pass those flags (or if it would even solve the problem).

Do you have any pointers that I could follow to debug this problem? Thanks!

[onelson]

The makefile generated by autotools et al does set -fPIC if I remember correctly. I'll use this as an invitation to finally setup travis for this repo and see if I can learn something about this. No idea off the top of my head.

As far as the crate is concerned, it treats the autotools build mostly as a black box. We link dynamic during development (since it's quicker to just depend on a distro .so) and build jq from source ourselves for production. I'm delighted to hear you were actually able to use this crate in alpine... I never thought to try it. At any rate, I'll try to reproduce and see if I can learn something.

Thanks for reporting!

[JeanMertz]

One more thing I noticed, that I can't quite explain, is that in the linked CI build above, the cargo build --all-features succeeds while the cargo test --all-features following thereafter fails to build.

I fail to see why one would succeed without compilation errors, and the other one wouldn't.

[onelson]

Yeah, I can't explain it either, however, I've been able to reproduce this in the jq-sys crate (now that I have travis setup for it). Running cargo test --features bundled will fail over there, even while building my testcrate (in this repo) will succeed.

Still, I think I've got a resolution on the way. I've got the CI for this crate now pulling in jq-sys so I can run a sort of integration test against it, leveraging the autogenerated bindgen test suite, and it looks like it's passing on travis with a small mod to the make invocation.

While I don't think it should be needed, and I don't know why it would be required when running in travis but not elsewhere, passing CFLAGS=-fPIC to make seems to paper over the issue.

[JeanMertz]

Still, I think I've got a resolution on the way.

Great to hear!

I'm relatively new to Rust, and only just picked up my first C book, so those flags are all magic to me, but I'm glad you knew where to look 😄.

[onelson]

I'm planning to cut a release this weekend, but if possible please add a patch to your Cargo.toml and re-run your travis job to verify the fix works for you.

[patch.crates-io]
jq-src = { git = "https://github.com/onelson/jq-src", branch = "master" }

[JeanMertz]

Thank you! And indeed, applying your patch solved the problem. 🎉

[onelson]

Released as 0.4.1. Now, on to the next thing on the list!