Open nazar-pc opened 7 years ago
You may want to check your link line - that shouldn't happen unless you're linking against the library twice by accident.
I think you're right, however, I'm not really sure how to do this correctly. What I'm doing is compiling noise-c alongside with one additional file using Emscripten.
Important pieces are LLVM options:
-include ed25519_random_and_hash.c -I vendor/include -I vendor/include/noise/keys -I vendor/src -I vendor/src/protocol -I vendor/src/crypto/goldilocks/src/include -I vendor/src/crypto/goldilocks/src/p448 -I vendor/src/crypto/goldilocks/src/p448/arch_32
And list of files to compile:
noise-c.c vendor/src/protocol/cipherstate.c vendor/src/protocol/dhstate.c vendor/src/protocol/errors.c vendor/src/protocol/handshakestate.c vendor/src/protocol/hashstate.c vendor/src/protocol/internal.c vendor/src/protocol/names.c vendor/src/protocol/patterns.c vendor/src/protocol/randstate.c vendor/src/protocol/signstate.c vendor/src/protocol/symmetricstate.c vendor/src/protocol/util.c vendor/src/protocol/../backend/ref/dh-curve448.c vendor/src/protocol/../backend/ref/dh-newhope.c vendor/src/protocol/../backend/ref/hash-blake2s.c vendor/src/protocol/../crypto/blake2/blake2s.c vendor/src/protocol/../crypto/curve448/curve448.c vendor/src/protocol/../crypto/goldilocks/src/p448/arch_32/p448.c vendor/src/protocol/../crypto/newhope/batcher.c vendor/src/protocol/../crypto/newhope/error_correction.c vendor/src/protocol/../crypto/newhope/fips202.c vendor/src/protocol/../crypto/newhope/newhope.c vendor/src/protocol/../crypto/newhope/ntt.c vendor/src/protocol/../crypto/newhope/poly.c vendor/src/protocol/../crypto/newhope/precomp.c vendor/src/protocol/../crypto/newhope/reduce.c vendor/src/protocol/../backend/ref/cipher-aesgcm.c vendor/src/protocol/rand_os.c vendor/src/protocol/../backend/ref/cipher-aesgcm.c vendor/src/protocol/../backend/ref/cipher-chachapoly.c vendor/src/protocol/../backend/ref/dh-curve25519.c vendor/src/protocol/../backend/ref/hash-blake2b.c vendor/src/protocol/../backend/ref/hash-sha256.c vendor/src/protocol/../backend/ref/hash-sha512.c vendor/src/protocol/../backend/ref/sign-ed25519.c vendor/src/protocol/../crypto/aes/rijndael-alg-fst.c vendor/src/protocol/../crypto/blake2/blake2b.c vendor/src/protocol/../crypto/chacha/chacha.c vendor/src/protocol/../crypto/donna/poly1305-donna.c vendor/src/protocol/../crypto/ghash/ghash.c vendor/src/protocol/../crypto/newhope/crypto_stream_chacha20.c vendor/src/protocol/../crypto/sha2/sha256.c vendor/src/protocol/../crypto/sha2/sha512.c vendor/src/protocol/../crypto/ed25519/ed25519.c
noise-c.c
is the file that I wrote and that contains:
#include <stdlib.h>
#include <noise/protocol.h>
#include <protocol/internal.h>
#include <protocol/randstate.c>
#include <noise/keys/certificate.h>
#include <keys/certificate.c>
I might say something stupid, since I'm not C developer even remotely, but I think Emscripten takes all of those files, creates object files for each source file specified and then link them together. Which is why *.c
files become a problem for me, functions from there are included once in file I wrote and once in some other noise-c's files.
Isn't that struct supposed to be opaque?
There is a struct
NoiseRandState_s
, it is defined insrc/protocol/randstate.c
file, which causes difficulties with linking when multiple files included this file:Similarly, for
_Noise_CertificateChain
,_Noise_Certificate
and_Noise_PrivateKey
I have to includesrc/keys/certificate.c
, which is not a problem for me yet, but it does include some functions and might become a problem later.Could you move those structs into
*.h
files with guarding from re-definition as it is for other structs already?