Duplicate definitions of Fp_model static members when using libsnark.so about libsnark HOT 3 OPEN

Note, this blog post describes the same kind of issue and introduces a new C++0x language extension to address the issue:

• https://anteru.net/2008/11/19/318/

Perhaps libsnark should use that mechanism?

from libsnark.

Ugh, how many hacky workarounds is C++ going to add in the language to address broken linker technology? :-/

from libsnark.

In libsnark each Fp_model<num_limbs, modulus> is used in conjunction with particular elliptic curve choices. Given this the following should work:

• in fp.hpp mark each static data member of Fp_model as extern. For example,

template<mp_size_t n, const bigint<n>& modulus>
extern size_t Fp_model<n, modulus>::num_bits

This would ensure that translation units for your executable won't declare their own copy of those symbols.

• For each use of Fp_model declare the static data members inside the CURVE_init.cpp. E.g. inside curves/bn128/bn128_init.cpp, we would have size_t Fp_model<bn128_r_limbs, bn128_modulus_r>::num_bits.

Of course, The amount of boilerplate can be reduced by an appropriate DECLARE_FP_MODEL_STATIC_MEMBERS(num_limbs, modulus) macro.

We rely on extern template anyway, so maybe solution based on that would be a better choice.

By the way, I was unable to exhibit the behavior you observe on my machine: all static members of template instantiations get "weak" bindings in libsnark.so so the dynamic linker should just DTRT. But that might just be an artifact of my setup (g++ 5.2.1 on Ubuntu wily).

from libsnark.