opencdk spkg should add $SAGE_LOCAL/lib to LDFLAGS

[rlm]

Willem explained this one to me. Apparently opencdk is now linking libgcrypt from the wrong place, due to libtools, caused by the addition of -lgcrypt in #8658. The short term fix is to make sure that $SAGE_LOCAL/lib is included in LDFLAGS in the spkg-install script, but the longer term fix will be to figure out why libtools is linking against /usr/lib in the first place.

[wjp]

Some relevant lines in the build log:

/bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -no-install  -o t-stream t-stream.o ../src/libopencdk.la -lgcrypt -lz

gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-stream t-stream.o  ../src/.libs/libopencdk.so /usr/lib64/libgcrypt.so -lz -Wl,--rpath -Wl,/data2/wpalenst/sage-4.4.4/spkg/build/opencdk-0.6.6.p4/src/src/.libs -Wl,--rpath -Wl,/data2/wpalenst/sage-4.4.4/local/lib
../src/.libs/libopencdk.so: undefined reference to `gcry_cipher_setkey@GCRYPT_1.2'
../src/.libs/libopencdk.so: undefined reference to `gcry_cipher_setiv@GCRYPT_1.2'

On another machine on which I've tried, opencdk also ended linking its tests against /usr/lib64/libgcrypt.so, but it didn't cause an error there.

[wjp]

Some more preliminary results:

It seems that adding $SAGE_LOCAL/lib to $LIBRARY_PATH as sage-env does, might have unexpected effects:

On 64 bit gentoo:

$ export LIBRARY_PATH=/blah
$ gcc -print-search-dirs
[...]
libraries: =/blah/x86_64-pc-linux-gnu/4.1.2/:/blah/../lib64/

So $SAGE_LOCAL/lib does _not_ end up being searched by gcc in this case. (But the non-existent $SAGE_LOCAL/lib64 does.)

On 64 bit debian (Lenny), this is

libraries: =/blah/x86_64-linux-gnu/4.3.2/:/blah/../lib/

It looks like we're completely mis-using LIBRARY_PATH... Maybe it's worth considering putting -L$SAGE_LOCAL/lib in $LDFLAGS in sage-env.

[wjp]

New spkg with the LDFLAGS workaround:

​http://www.math.leidenuniv.nl/~wpalenst/sage/opencdk-0.6.6.p5.spkg