Perl-5.28 und OpenSSL

[GerhardJ]

Hallo zusammen,

ich habe auf meine NAS.5.40 (Linux NAS540 3.2.54 #1 SMP Tue May 22 01:36:44 CST 2018 armv7l GNU/Linux) seit langer Zeit entware-ng und "FHEM" am Laufen. FHEM basiert auf Perl und verlangt nach jedem Perl Update, dass ich verschiedene Module compilieren muss. Hat bisher sehr gut funktioniert:

Beschreibung: https://github.com/Entware-ng/Entware-n ... ilation%29
wget -qO- http://pkg.entware.net/binaries/armv7/i ... ude.tar.gz | tar xvz -C /opt/include
source /opt/bin/gcc_env.sh
perl -MCPAN -e shell

Nach dem letzten Update habe ich allerdings Probleme beim Perl-Modul "Net::SSLeay". Dieses benötigt libssl. Diese lib ist seit dem letzten Update in unterschiedlicher Variante vorhanden:
/opt/lib/libssl.so.1.1
und
/usr/lib/libssl.so
/usr/lib/libssl.so.1.0.0

Beim Compilieren sehe ich, dass via -L/usr und -L/usr/lib die libssl.o von /usr genommen wird. Was wohl falsch ist.

Compiler Output:

Code: Select all

arm-openwrt-linux-gnueabi-gcc -c   -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=soft -I/media/ware3/Entware.2019.05/staging_dir/target-arm_cortex-a9_glibc-2.23_eabi/opt/include -I/media/ware3/Entware.2019.05/staging_dir/toolchain-arm_cortex-a9_gcc-7.4.0_glibc-2.23_eabi/include -O2   -DVERSION=\"1.88\" -DXS_VERSION=\"1.88\" -fPIC "-I/opt/lib/perl5/5.28/CORE"   SSLeay.c

rm -f blib/arch/auto/Net/SSLeay/SSLeay.so
LD_RUN_PATH="/usr/lib" arm-openwrt-linux-gnueabi-gcc  -shared -L/usr -L/usr/lib -L/media/ware3/Entware.2019.05/staging_dir/target-arm_cortex-a9_glibc-2.23_eabi/opt/lib  SSLeay.o  -o blib/arch/auto/Net/SSLeay/SSLeay.so  \
   -L/usr -L/usr/lib -lssl -lcrypto -lz   \
  
chmod 755 blib/arch/auto/Net/SSLeay/SSLeay.so
  CHRISN/Net-SSLeay-1.88.tar.gz
  /opt/bin/make -- OK

Soweit so gut. Die Tests gehen dann in die Hose:

Code: Select all

#     Error:  Can't load '/i-data/70be7240/root/.cpan/build/Net-SSLeay-1.88-10/blib/arch/auto/Net/SSLeay/SSLeay.so' for module Net::SSLeay: libssl.so.1.0.0: cannot open shared object file: No such file or directory at /opt/lib/perl5/5.28/DynaLoader.pm line 159.

Ich gehe mal davon aus, dass eigentlich die libssl aus "/opt/lib" korrekt wäre.

Also geforscht und folgendes gefunden:

Code: Select all

OPENSSL_PREFIX=/opt perl -MCPAN -e shell

Code: Select all

arm-openwrt-linux-gnueabi-gcc -c  -I"/opt/include" -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=soft -I/media/ware3/Entware.2019.05/staging_dir/target-arm_cortex-a9_glibc-2.23_eabi/opt/include -I/media/ware3/Entware.2019.05/staging_dir/toolchain-arm_cortex-a9_gcc-7.4.0_glibc-2.23_eabi/include -O2   -DVERSION=\"1.88\" -DXS_VERSION=\"1.88\" -fPIC "-I/opt/lib/perl5/5.28/CORE"   SSLeay.c
rm -f blib/arch/auto/Net/SSLeay/SSLeay.so
LD_RUN_PATH="/opt/lib" arm-openwrt-linux-gnueabi-gcc  -shared -L/opt -L/opt/lib -L/media/ware3/Entware.2019.05/staging_dir/target-arm_cortex-a9_glibc-2.23_eabi/opt/lib  SSLeay.o  -o blib/arch/auto/Net/SSLeay/SSLeay.so  \
   -L/opt -L/opt/lib -lssl -lcrypto -lz   \
  
chmod 755 blib/arch/auto/Net/SSLeay/SSLeay.so
  CHRISN/Net-SSLeay-1.88.tar.gz
  /opt/bin/make -- OK

Das sieht ja mal gut aus: -L/opt -L/opt/usr ...
*ABER*:

Code: Select all

PERL_DL_NONLAZY=1 "/opt/bin/perl5.28.1" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/local/*.t t/handle/local/*.t
t/handle/local/05_use.t ................ 1/1 
#   Failed test 'use Net::SSLeay::Handle;'
#   at t/handle/local/05_use.t line 8.
#     Tried to use 'Net::SSLeay::Handle'.
#     Error:  Can't load '/i-data/70be7240/root/.cpan/build/Net-SSLeay-1.88-16/blib/arch/auto/Net/SSLeay/SSLeay.so' for module Net::SSLeay: libssl.so.1.0.0: cannot open shared object file: No such file or directory at /opt/lib/perl5/5.28/DynaLoader.pm line 159.

Warum um alles in der Welt wird versucht libssl.so.1.0.0 zu verwenden?

Folgender Aufruf - wäre wahrscheinlich korrekt - führt zu einem weiteren Problem:

Code: Select all

LD_LIBRARY_PATH=/opt/lib LD_RUN_PATH=/opt/lib OPENSSL_PREFIX=/opt perl -MCPAN -e shell

/bin/pwd: error while loading shared libraries: /opt/lib/libm.so.6: internal error

Irgendwelche Ideen?

Könnte ich evtl. ein Downgrade zu Perl-5.26 machen?

Danke und Grüße
Gerhard

[Mijzelf]

I think the compiler/linker by default doesn't address the /opt prefix. If you run

Code: Select all

ldd /i-data/70be7240/root/.cpan/build/Net-SSLeay-1.88-10/blib/arch/auto/Net/SSLeay/SSLeay.so

it will show you a 'not found' for libssl.so.1.0.0, because is searches in /lib and /usr/lib.
That seems strange, as at link time the library was findable, but not at runtime.

The output for the original linking is

Code: Select all

LD_RUN_PATH="/usr/lib" arm-openwrt-linux-gnueabi-gcc  -shared -L/usr -L/usr/lib -L/media/ware3/Entware.2019.05/staging_dir/target-arm_cortex-a9_glibc-2.23_eabi/opt/lib  SSLeay.o  -o blib/arch/auto/Net/SSLeay/SSLeay.so  \
   -L/usr -L/usr/lib -lssl -lcrypto -lz   \

but I think that should be

Code: Select all

LD_RUN_PATH="/opt/lib" arm-openwrt-linux-gnueabi-gcc  -shared -L/opt/lib -L/media/ware3/Entware.2019.05/staging_dir/target-arm_cortex-a9_glibc-2.23_eabi/opt/lib  SSLeay.o  -o blib/arch/auto/Net/SSLeay/SSLeay.so  \
   -L/opt/lib -lssl -lcrypto -lz   \

to get a valid 'Entware perl' library. Of course /opt/lib/libssl, /opt/lib/libcrypto and /opt/lib/libz should be present. An Entware compatible library should stay inside /opt.

LD_LIBRARY_PATH should be able to solve this, but unfortunately somewhere pwd is called, which is forced to use the wrong library. If /opt/bin/pwd had been used, this would have been no problem.

[GerhardJ]

Thanks for your thoughts. /bin/pwd is a statically linked binary (in fact a symbolic link to /bin/busybox).
For completion:

Code: Select all

arm-openwrt-linux-gnueabi-gcc -c  -I"/opt/include" -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=soft -I/media/ware3/Entware.2019.05/staging_dir/target-arm_cortex-a9_glibc-2.23_eabi/opt/include -I/media/ware3/Entware.2019.05/staging_dir/toolchain-arm_cortex-a9_gcc-7.4.0_glibc-2.23_eabi/include -O2   -DVERSION=\"1.88\" -DXS_VERSION=\"1.88\" -fPIC "-I/opt/lib/perl5/5.28/CORE"   SSLeay.c
rm -f blib/arch/auto/Net/SSLeay/SSLeay.so
LD_RUN_PATH="/opt/lib" arm-openwrt-linux-gnueabi-gcc  -shared -L/opt -L/opt/lib -L/media/ware3/Entware.2019.05/staging_dir/target-arm_cortex-a9_glibc-2.23_eabi/opt/lib  SSLeay.o  -o blib/arch/auto/Net/SSLeay/SSLeay.so  \
   -L/opt -L/opt/lib -lssl -lcrypto -lz   \
  
chmod 755 blib/arch/auto/Net/SSLeay/SSLeay.so
  CHRISN/Net-SSLeay-1.88.tar.gz

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)

And yes: libssl.so and libcrypto.so are available in /opt/lib. I don't understand, why the linker (see above) obviously uses the correct path for these libraries, but the result is crap

Regarding the segmentation fault in libm: Could it be that my installation is crap? The entware repository says that libc-2.27 is the latest one. Here I have 2.23 and opkg does not provide further updates..

[GerhardJ]

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.

Another statically linker binary on that box is python. When calling that one with LD_LIBRARY_PATH set,
I get:

Code: Select all

python: error while loading shared libraries: /opt/lib/libpthread.so.0: internal error

Why that? Which program-loader is involved when starting python in that case? It looks to me as my installation is corrupted and the preinstalled stuff does not work with the entware stuff

[Mijzelf]

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.