Open copumpkin opened 6 years ago
Hi @copumpkin,
I also faced the first issue that you have mentioned above, when trying to use libsnark as a library inside a library that I am creating. May I know how did you fix it please? Thank you. Hasini.
I recommend adding libsnark as a native dependency to your development environment. I've made a tutorial repo that includes a development environment with libsnark imported in this fashion: https://github.com/howardwu/libsnark-tutorial
Hi @howardwu,
Thank you for the quick reply.I appreciate it. I have followed your tutorial (as I have mentioned in another issue as well) and it works perfectly fine when I add libsnark as a native dependency. But my goal is to create a library of my own (say libX) which uses libsnark as a library and call libX from a program written in Go. That is why I can not use libnark as a native dependency and looking further for using it as a linked library.
Thank you. Hasini.
The main issue with linking libsnark is that it makes timely deployment of fixes and updates to libsnark cumbersome. I see how a linked library can be useful in your case. The make install
components remain intact in libff
and libfqfft
. Would adding a boolean flag to link these dependencies in the libsnark compilation process resolve your issue?
Yes, that would be very helpful. Thank you.
I've added a flag, which when toggled, will use installed libff
and libfqfft
libraries rather than using them as native dependencies. (https://github.com/scipr-lab/libsnark/commit/74eda8ae599b4a5bcf583d23491de47f530d5195)
To use this feature, from the build
folder, run:
cmake -DUSE_LINKED_LIBRARIES=ON ..
Note: You will need to make install
both libff
and libfqfft
in accordance to their respective build instructions.
Tested on Ubuntu 14.04.
I'm not sure which of the scipr-lab repositories to file this against, so apologies if I'm sending this to the wrong place.
I'm packaging libsnark in nixpkgs and have had to patch over several weird issues in the CMake build in order to get a working package out of it.
Here's what I've found so far:
libfqfft
's CMakeLists.txt only callsadd_subdirectory(libfqfft)
ifIS_LIBFQFFT_PARENT
is set, whichlibsnark
obviously doesn't set. This preventslibfqfft
headers from getting installed when installinglibsnark
.libzm.a
fromate-pairing
never gets installed. Thedepends
CMakeLists.txt adds a library for it, but never adds install instructions for it, solibzm.a
just sits in thedepends
build directory and never makes it to the install target. This prevents any downstream libraries depending onlibsnark
from getting a bunch of symbols they need fromate-pairing
, unless they manually depend on thelibsnark
build directory.libff
's headers (I already filed a bug against that repo, but figured I'd mention it here too) seem to#include "depends/..."
stuff fromate-pairing
, which breaks horribly when talking about installed libraries. I was able to make it all work by manually installing theate-pairing
headers and patching them to#include
angle-bracketed versions of the headers, but that doesn't seem like it should be necessary.cc @madars