Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

issue with libssl not having "sk_num" #32

Open
GildedHonour opened this issue Jun 6, 2018 · 5 comments
Open

issue with libssl not having "sk_num" #32

GildedHonour opened this issue Jun 6, 2018 · 5 comments

Comments

@GildedHonour
Copy link

GildedHonour commented Jun 6, 2018

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
Copy link
Author

No idea?

@Altai-man
Copy link
Member

@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
Copy link
Contributor

cono commented Jun 11, 2018

@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
Copy link
Member

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

@GildedHonour
Copy link
Author

I don't use it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants