I tried building nettle 1.6 with --enabled-shared on Red Hat Linux 8.0 on x86.
The command to build the shared library doesn't get the soname or the filename correct:
gcc -shared -Wl,-soname=libnettle.so. aes_p.o [...] nettle-openssl_p.o -o libnettle.so
The attached patch fixes the problem.
The example programs are built like this:
[...] ../libnettle.a -lcrypto -lgmp
In order to test the shared libraries, that needs to be something like this:
[...] -L.. -lnettle -lcrypto -lgmp
That will work even if a shared library wasn't build. The example programs will need to be invoked with LD_LIBRARY_PATH set appropriately.
However, when I tested linking one of the example programs with the shared library, it failed:
gcc -I.. -g -O2 -ggdb3 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -o rsa-keygen rsa-keygen.o io.o -L.. -lnettle -lcrypto -lgmp ../libnettle.so: undefined reference to `memxor' collect2: ld returned 1 exit status
I haven't had time to look at this one any further...
Regards,
James Ralston qralston+ml.nettle-bugs@andrew.cmu.edu writes:
I tried building nettle 1.6 with --enabled-shared on Red Hat Linux 8.0 on x86.
Thanks for testing this.
The command to build the shared library doesn't get the soname or the filename correct:
gcc -shared -Wl,-soname=libnettle.so. aes_p.o [...] nettle-openssl_p.o -o libnettle.soThe attached patch fixes the problem.
I've applied the patch.
There seems to be one more problem with that command line: nettle-openssl_p.o should probably not be included in the shared library. It is used only for benchmarking against openssl, and including it in the shared library will make the entire library depend on openssl, which isn't good. Perhaps the file should simply be moved out of the library and down into the examples directory. The same will apply whenever I add similar glue code for libgcrypt.
The example programs are built like this:
[...] ../libnettle.a -lcrypto -lgmpIn order to test the shared libraries, that needs to be something like this:
[...] -L.. -lnettle -lcrypto -lgmp
Fixed.
That will work even if a shared library wasn't build. The example programs will need to be invoked with LD_LIBRARY_PATH set appropriately.
And I added a line to the testsuite and examples Makefiles to set LD_LIBRARY_PATH when running the tests. Actually, I set it to ../.lib, and install a link from .lib/libnettle.so.0 to libnettle.so.
../libnettle.so: undefined reference to `memxor'
memxor should be included in the library, via LIBOBJS, but that didn't happen. Fixed.
Can you try getting the current nettle from cvs and check if that works? It should be something like
cvs -d :pserver:anonymous@cvs.lysator.liu.se:/cvsroot/lsh co nettle cd nettle ./.bootstrap && configure --enable-shared && make && make check
(You may not want to install it, I won't promise that the current nettle is compatible with 1.6 nor with the next released version).
Thanks, /Niels
On 2002-11-01 (Friday) at 11:32:26+0100 Niels Möller nisse@lysator.liu.se wrote:
Thanks for testing this.
Not a problem; thanks for all of your work on lsh/nettle.
There seems to be one more problem with that command line: nettle-openssl_p.o should probably not be included in the shared library. It is used only for benchmarking against openssl, and including it in the shared library will make the entire library depend on openssl, which isn't good.
Agreed. (I was a bit surprised when I noticed the dependency, but I wasn't sure why it was there.)
Perhaps the file should simply be moved out of the library and down into the examples directory. The same will apply whenever I add similar glue code for libgcrypt.
That seems like a reasonable solution.
Can you try getting the current nettle from cvs and check if that works?
I found one problem (a simple variable renaming error); the enclosed patch fixes it.
With the patch, as of today, current CVS works fine (with both --enabled-shared and --disabled-shared) on Red Hat Linux 8.0 (x86 architecture; gcc 3.2).
I also tried to compile on Sun Solaris 8 (sparc; SunPro 5.2 2000/09/11), but the SunPro CC doesn't ISO C99 non-constant initializers:
source='des-compat.c' object='des-compat.o' libtool=no \ depfile='.deps/des-compat.Po' tmpdepfile='.deps/des-compat.TPo' \ depmode=none /bin/bash ./depcomp \ /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I. -I. -g -c `test -f 'des-compat.c' || echo './'`des-compat.c "des-compat.c", line 64: non-constant initializer: op "NAME" "des-compat.c", line 64: non-constant initializer: op "NAME" "des-compat.c", line 64: non-constant initializer: op "NAME" "des-compat.c", line 145: non-constant initializer: op "NAME" "des-compat.c", line 145: non-constant initializer: op "NAME" "des-compat.c", line 145: non-constant initializer: op "NAME" cc: acomp failed for des-compat.c *** Error code 2 make: Fatal error: Command failed for target `des-compat.o' Current working directory /tmp/qralston/nettle.CVS-2002-11-07 *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /tmp/qralston/nettle.CVS-2002-11-07 *** Error code 1 make: Fatal error: Command failed for target `all'
If compatibility with SunPro CC is desired, I'll go ahead and construct a patch to work around its limitation; let me know.
(You may not want to install it, I won't promise that the current nettle is compatible with 1.6 nor with the next released version).
Thanks for the warning. (I don't plan to use it in production; I was mostly just interested in testing it out.)
Regards, James
James Ralston qralston+ml.nettle-bugs@andrew.cmu.edu writes:
On 2002-11-01 (Friday) at 11:32:26+0100 Niels Möller nisse@lysator.liu.se wrote:
... about nettle-openssl.c ...
Perhaps the file should simply be moved out of the library and down into the examples directory. The same will apply whenever I add similar glue code for libgcrypt.
That seems like a reasonable solution.
Moved now.
I found one problem (a simple variable renaming error); the enclosed patch fixes it.
Fixed. For some reason my testutils.c file wasn't recompiled since I made that change.
I also tried to compile on Sun Solaris 8 (sparc; SunPro 5.2 2000/09/11), but the SunPro CC doesn't ISO C99 non-constant initializers:
Fixed now, I hope. It's annoying that some compilers handle only constant aggregate initializers, but I guess we just have to live with that. Nettle is intended to be portable to any system with an ANSI-C compiler.
Regards, /Niels
--On Friday, November 08, 2002 10:12:37 +0100 Niels Möller nisse@lysator.liu.se> wrote:
James Ralston qralston+ml.nettle-bugs@andrew.cmu.edu writes:
I also tried to compile on Sun Solaris 8 (sparc; SunPro 5.2 2000/09/11), but the SunPro CC doesn't ISO C99 non-constant initializers:
Fixed now, I hope. It's annoying that some compilers handle only constant aggregate initializers, but I guess we just have to live with that. Nettle is intended to be portable to any system with an ANSI-C compiler.
Well, I gave it another shot on Solaris 8, using a fresh CVS checkout that I grabbed at 2002-12-12T02:25-0500. AFAICT, the non-constant aggregate initializers are no longer a problem.
Is it your intent to have nettle require GNU MP? I don't have it installed on this particular Solaris box; as a result, anything that includes rsa.h fails to compile, because rsa.h unconditionally includes <gmp.h>.
Regards, James
James Ralston qralston+ml.nettle-bugs@andrew.cmu.edu writes:
Is it your intent to have nettle require GNU MP?
The idea is that the publickey algorithms require GMP. So if you compile on a system without GNU MP that more or less implies --disable-public-key. And then the rsa functions are unavailable.
I don't have it installed on this particular Solaris box; as a result, anything that includes rsa.h fails to compile, because rsa.h unconditionally includes <gmp.h>.
If it avoided the inclusion of "gmp.h", and the program *uses* some rsa function, then it would just fail at link time instead. GMP is needed for rsa.
There is actually one unfortunate sideeffect of the gmp dependency, when using the shared library: If you write a program that uses only the symmetric functions of nettle (i.e. no rsa), and you link dynamically, and nettle was compiled with public key support, then you need to link with GMP as well, even if it won't be used. With static linking, only object files that are referred to are dragged into the executable, so if one doesn't call any (funcction in some) object file that in turn calls GMP, there's no need to link with GMP. Dynamic linking doesn't look at individual object files, it's an all-or-nothing thing.
Suggestions on how to improve this situation is appreciated.
Regards, /Niels
--On Thursday, December 12, 2002 09:31:07 +0100 Niels Möller nisse@lysator.liu.se wrote:
If it avoided the inclusion of "gmp.h", and the program *uses* some rsa function, then it would just fail at link time instead. GMP is needed for rsa.
But --disable-public-key doesn't make it so that GMP isn't needed, and configure won't abort if it fails to detect GMP.
I don't have any strong opinions on whether GMP is needed. But if it *is* needed, then configure should die if it can't find GMP, rather than giving the builder the illusion that typing "make" can actually succeed. ;)
If you write a program that uses only the symmetric functions of nettle (i.e. no rsa), and you link dynamically, and nettle was compiled with public key support, then you need to link with GMP as well, even if it won't be used. With static linking, only object files that are referred to are dragged into the executable, so if one doesn't call any (function in some) object file that in turn calls GMP, there's no need to link with GMP. Dynamic linking doesn't look at individual object files, it's an all-or-nothing thing.
True; this is the price one pays for the advantages gained by dynamic linking.
Suggestions on how to improve this situation is appreciated.
Alas, I know of no easy solution.
The general "solution" (and I use that term lightly) for this problem is to isolate the functions that have dependencies on other libraries in another (separate) library; e.g., libnettle and libnettle_pubkey. But in the vast majority of cases, this "solution" is far more trouble than it's worth.
On the bright side, modern packaging systems (RPM, .deb, et. al.) tend to push the responsibility of dealing with stacked dynamic linking dependencies onto the packager, and away from end users of the package.
James
James Ralston qralston+ml.nettle-bugs@andrew.cmu.edu writes:
I don't have any strong opinions on whether GMP is needed. But if it *is* needed, then configure should die if it can't find GMP, rather than giving the builder the illusion that typing "make" can actually succeed. ;)
Ah, it seems I misunderstood you, I thought "anything that includes rsa.h fails to compile, because rsa.h unconditionally includes <gmp.h>" referred to some other program *using* nettle, not files that are part of nettle.
If making nettle fails when there's no GMP available, that's definitely a bug. Please provide error messages, version info etc.
The intended behaviour in this case is to build a nettle library without any public-key support.
Regards, /Niels
--On Friday, December 13, 2002 09:44:49 +0100 Niels Möller nisse@lysator.liu.se wrote:
If making nettle fails when there's no GMP available, that's definitely a bug. Please provide error messages, version info etc.
See the attached files.
I'm not what type of fix to suggest--multiple files break if GMP and/or public key support isn't available...
Regards, James
James Ralston qralston+ml.nettle-bugs@andrew.cmu.edu writes:
I'm not what type of fix to suggest--multiple files break if GMP and/or public key support isn't available...
I've now checked in the following changes,
2002-12-30 Niels Möller nisse@cuckoo.hack.org
* testsuite/rsa2sexp-test.c: Don't include rsa.h (done by testutils.h, if enabled). * testsuite/sexp2rsa-test.c: Likewise.
* rsa-decrypt.c: Make compilation conditional on WITH_PUBLIC_KEY. * rsa-encrypt.c: Likewise. * rsa-compat.c: Likewise.
Please try the cvs version and see if it works better. (For now, I've only tried with --disable-public-key, and checking that no files try including rsa.h or dsa.h. I haven't actually tried uninstalling gmp).
Thanks for the report, and a happy new year, /Niels
nettle-bugs@lists.lysator.liu.se
-
James Ralston -
nisse＠lysator.liu.se