croservices / cro-http

HTTP (including HTTPS and HTTP/2) support for the Cro library for building distributed systems in Raku.
https://cro.services/
Artistic License 2.0
49 stars 26 forks source link

issue with libssl not having "sk_num" #32

Open GildedHonour opened 6 years ago

GildedHonour commented 6 years ago

I'm on Arch linux, that is, the system is up to date. And I have this exception:

When installing a dependency, I get this exception when installing Cro::Router:

  ===> Testing: IO::Socket::Async::SSL:ver<0.7.0>
  Cannot locate symbol 'sk_num' in native library 'libssl.so'
    in method setup at /usr/share/perl6/sources/24DD121B5B4774C04A7084827BFAD92199756E03 (NativeCall) line 291
    in method CALL-ME at /usr/share/perl6/sources/24DD121B5B4774C04A7084827BFAD92199756E03 (NativeCall) line 570
    in block  at /home/me123/.zef/store/IO-Socket-Async-SSL-0.7.0.tar.gz/IO-Socket-Async-SSL-0.7.0/lib/IO/Socket/Async/SSL.pm6 (IO::Socket::Async::SSL) line 436
    in block  at /home/me123/.zef/store/IO-Socket-Async-SSL-0.7.0.tar.gz/IO-Socket-Async-SSL-0.7.0/lib/IO/Socket/Async/SSL.pm6 (IO::Socket::Async::SSL) line 401
    in block <unit> at t/client-server.t line 171

  ===> Testing [FAIL]: IO::Socket::Async::SSL:ver<0.7.0>
  Aborting due to test failure: IO::Socket::Async::SSL:ver<0.7.0> (use --force-test to override)
    in code  at /usr/share/perl6/vendor/sources/7926F4F3ED4C81AA5DA2A54C8AE1E03D03424CCE (Zef::Client) line 375
    in method test at /usr/share/perl6/vendor/sources/7926F4F3ED4C81AA5DA2A54C8AE1E03D03424CCE (Zef::Client) line 355
    in code  at /usr/share/perl6/vendor/sources/7926F4F3ED4C81AA5DA2A54C8AE1E03D03424CCE (Zef::Client) line 531
    in sub  at /usr/share/perl6/vendor/sources/7926F4F3ED4C81AA5DA2A54C8AE1E03D03424CCE (Zef::Client) line 528
    in method install at /usr/share/perl6/vendor/sources/7926F4F3ED4C81AA5DA2A54C8AE1E03D03424CCE (Zef::Client) line 623
    in sub MAIN at /usr/share/perl6/vendor/sources/E4784A2A0FA00D16808817186E95FE74BEF3FE2D (Zef::CLI) line 152
    in block <unit> at /usr/share/perl6/vendor/resources/3065D08F5332CA244672D7F8A05B603F92BB8A7D line 3
    in sub MAIN at /usr/share/perl6/vendor/bin/zef line 2
    in block <unit> at /usr/share/perl6/vendor/bin/zef line 2

Is there a workaround for it? At the moment I only want to install everything and be able to run it.

GildedHonour commented 6 years ago

No idea?

Altai-man commented 6 years ago

@GildedHonour hello, thanks for your feedback. I personally use LibreSSL 2.7.3 and other folks with different versions of OpenSSL seem to have no not encountered this issue, so I am not sure what can be wrong with Arch version. I think it should be fresh enough... Anyway, as a workaround: you can always force tests to pass with --force option(e.g. zef --force install IO::Socket::Async::SSL) and continue to install cro-http with the dependency in place. You will likely be unable to run https-based applications, but it'd be totally fine for http/zmq/other types of services.

cono commented 6 years ago

@GildedHonour would you mind to provide following information:

objdump -x /usr/lib64/libssl.so | grep SONAME
file -L /usr/lib/libssl.so

Most probably you have more recent library than P6 OpenSSL was built for. Because OpenSSL library trying to dlopen linker file instead of proper SONAME. https://github.com/sergot/openssl/blob/master/lib/OpenSSL/NativeLib.pm6

And this is not good, more explained here: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

I would rather create a ticket against OpenSSL to rewrite it to support particular SONAME and let maintainers of the OS decide what p6 library openssl version should be used.

Especially taking into account that a lot of shared libraries linked names are LD scripts, so dlopen will definitely fail on them, e.g.:

cat /usr/lib64/libreadline.so 
/* GNU ld script
   Since Gentoo has critical dynamic libraries in /lib, and the static versions
   in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we
   run into linking problems.  This "fake" dynamic lib is a linker script that
   redirects the linker to the real lib.  And yes, this works in the cross-
   compiling scenario as the sysroot-ed linker will prepend the real path.

   See bug https://bugs.gentoo.org/4411 for more info.
 */
OUTPUT_FORMAT ( elf64-x86-64 )
GROUP ( /lib64/libreadline.so.7 )
Altai-man commented 6 years ago

ping @GildedHonour The issue should be fixed now, can you please confirm?

GildedHonour commented 6 years ago

I don't use it