Re: libnettle/libhogweed WIP

[Eli Zaretskii <eliz@gnu.org>]

> From: Ted Zlatanov <tzz@lifelogs.com>
> 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.