64 bit Edge Openssl Does Not Like Me

‹prev | My Chain | next›

Tonight I think I will explore node-spdy a little. Especially after it helped me solve my minor zlib issue yesterday, I am eager to kick the tires.

Unfortunately, things get off to a poor start:

➜  test git:(master) ✗ node spdy-server.js 

node.js:183
        throw e; // process.nextTick error, or 'error' event on first tick
        ^
You're using not NPN-enabled version of node.js

Hunh? I know I installed it against the NPN-enabled openssl. What does ldd tell me?

➜  test git:(master) ✗ pwd           
/home/cstrom/repos/node-spdy/test
➜  test git:(master) ✗ which node
/home/cstrom/local/node-v0.5.0-pre/bin/node
➜  test git:(master) ✗ ldd `which node`
        linux-vdso.so.1 =>  (0x00007fff4f2bc000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6a4e4b7000)
        libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x00007f6a4e264000)
        libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x00007f6a4ded4000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6a4dcd0000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f6a4dacd000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6a4d7c6000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6a4d541000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6a4d32b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6a4d10c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6a4cd78000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6a4e6e7000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6a4cb60000)

Now just a cotton picking second. How is that linked against the old 0.9 openssl libraries, I very specifically built it against the 1.0 / NPN enabled version of openssl:

./configure --openssl-includes=$HOME/local/include/openssl --openssl-libpath=$HOME/local/lib/openssl --prefix=$HOME/local/node-v0.5.0-pre

But... there are no openssl shared libraries in my $HOME/local directory:

/home/cstrom/local/lib/pkgconfig/openssl.pc
➜  test git:(master) ✗ find $HOME/local/lib | grep openssl\.\*so

Well, that explains why node is linked against the system (old) openssl. But what gives?

Eventually, I realize that I ought to be able to build the shared objects directly:

➜  openssl  make libssl.so.1.1.0               
make[1]: Entering directory `/home/cstrom/repos/openssl'
make[2]: Entering directory `/home/cstrom/repos/openssl'
/usr/bin/ld: libcrypto.a(e_gost_err.o): relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC
libcrypto.a(e_gost_err.o): could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [link_a.gnu] Error 1
make[2]: Leaving directory `/home/cstrom/repos/openssl'
make[1]: *** [do_linux-shared] Error 2
make[1]: Leaving directory `/home/cstrom/repos/openssl'
make: *** [libcrypto.so.1.1.0] Error 2

Grrr...

I find an open openssl ticket which seem vaguely similar. So I download an apply the second patch:

➜  openssl  wget http://rt.openssl.org/Ticket/Attachment/30213/15460/openssl-dev.diff
➜  openssl  patch -p0 < openssl-dev.diff     
patching file crypto/aes/asm/aes-x86_64.pl
patching file crypto/rc4/asm/rc4-x86_64.pl
patching file crypto/x86_64cpuid.pl

And then I run through the compilation steps one more time:

➜  openssl  ./config --prefix=$HOME/local
➜  openssl  make depend                  
➜  openssl  make

Unfortunately, I still end up with the same R_X86_64_32 relocation error. I try passing in various options (-fPIC and -m32), but to no avail. I just cannot seem to get this installed on a 64 bit system.

Ah well, definitely a worthwhile sidebar. I will pick this back up tomorrow by installing on my 32 bit VM. I will also pursue further on the openssl mailing list.


Day #19