For completion:
Code: Select all
The above leads indeed to a SSLeay.so like below:
Code: Select all
ldd /i-data/70be7240/root/.cpan/build/Net-SSLeay-1.88-0/blib/arch/auto/Net/SSLeay/SSLeay.so
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libz.so.1 => /opt/lib/libz.so.1 (0x2abc6000)
libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x2abe9000)
libc.so.6 => /opt/lib/libc.so.6 (0x2ac93000)
/opt/lib/ld-linux.so.3 (0x2ab2f000)
Didn't that version of SSLeay.so work in perl?
Some more stuff:
As soon, as I set LD_LIBRARY_PATH=/opt/lib, the busybox tools fail with:
Code: Select all
grep: error while loading shared libraries: /opt/lib/libm.so.6: internal error
I checked the ldconfig cache and see:
libm.so.6 (libc6,soft-float, OS ABI: Linux 2.6.32) => /opt/lib/libm.so.6
Could that be an issue? The kernel running is 3.2.54.
That behaviour is not unexpected. Busybox is not statically linked, but is linked against a certain version of libc. As in opensource world it is always possible to compile against the available libraries, the interfaces of the libraries are not rock stable, like the interfaces of -for instance- Windows libraries. And so you shouldn't be surprised when the compiled binary doesn't work well with another version of the same library.
For this reason you can't expect the firmware binaries work well with Entware libraries, and vice versa.
Using LD_LIBRARY_PATH you try to force SSLeay.so to use the libraries in /opt/lib, but because in the same session apparently firmware binaries are called, they are forced too, and that doesn't work.
Linux 2.6.32) => /opt/lib/libm.so.6
Could that be an issue? The kernel running is 3.2.54.
No. The kernel is (almost always) down compatible. The ABI used by the .so is the minimum kernel version. AFAIK all newer kernels are still compatible.