[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libnettle/libhogweed WIP
From: |
Eli Zaretskii |
Subject: |
Re: libnettle/libhogweed WIP |
Date: |
Sat, 18 Mar 2017 10:12:23 +0200 |
> From: Ted Zlatanov <address@hidden>
> Date: Fri, 17 Mar 2017 18:46:29 -0400
>
> >> * it compiles but doesn't link: "error adding symbols: DSO missing from
> >> command line" which I hope is something trivial
>
> EZ> Did the -lhogweed -lnettle switches appear on the link command line?
>
> Here's the full monster (I just did `./autogen.sh all && configure
> --with-nettle && make' on a Ubuntu system):
Looks like -lhogweed is not followed by -lnettle, perhaps that's the
problem.
> CCLD temacs
> /usr/bin/ld: nettle.o: undefined reference to symbol
> 'nettle_hmac_set_key@@NETTLE_6'
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libnettle.so: error
> adding symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
> Makefile:612: recipe for target 'temacs' failed
>
> I'm still not sure why it's failing. Is it the order of the libraries?
Probably.
> What does the error mean?
It means the linker didn't find that function in the libraries it
scanned after encountering the first reference to the function.
> EZ> . support for dynamic loading on MS-Windows should be added
>
> Can we agree that's a followup task?
Yes. Once you get the branch to a good shape, someone should add that
to the branch, before it is merged.
> EZ> . did you consider exposing this functionality through corresponding
> EZ> GnuTLS functions?
>
> I'm not sure what you mean.
AFAICT, GnuTLS exposes at least some of the functions you want to use,
so we could instead implement these APIs by calling GnuTLS.
> EZ> Another design question: should be support buffer regions, instead of
> EZ> strings, as input to these functions? The way your code is written,
> EZ> Lisp programs must always cons a string from buffer text, before they
> EZ> invoke these functions. This could be gratuitous cost in some use
> EZ> cases.
>
> Yes, but I think a low-level interface shouldn't know about buffers.
Why not?
> Right. But I can't pre-define the symbols because I don't know what
> hashes and ciphers will be dynamically available.
You could intern all the symbols at startup time, or the first time
any of these functions is called.
> So is it OK to check if the symbol name equals a C string?
You have SYMBOL_NAME for that. But I think interning the symbols at
startup is better.
> Is there a fast safe way to do
> that (considering that symbol names have a pretty rich charset)?
Not sure what you mean: since the internal representation is a
superset of UTF-8, strcmp should work just fine, no?
> EZ> Once again, since the length is known in advance, producing output
> EZ> into an allocated buffer and then creating a Lisp string by copying
> EZ> that buffer is wasteful. It is better to produce output directly into
> EZ> a string's data.
>
> I don't know enough about the Lisp string internals to do this safely.
That's the same comment about make_uninit_string above.
Thanks.
Re: request to reconsider libnettle/libhogweed, Paul Eggert, 2017/03/02