p5-net-ssleay
p5-net-ssleay copied to clipboard
XS code assumes that USE_ITHREADS means that the `threads` package is actually loaded
I'm running into a problem with a thread-compiled 5.18.2 Perl that tries to load in Net::SSLeay and fails:
XSLoader at dev-perl/centos7/5.18.2/lib/perl5/XSLoader.pm line 90.
XSLoader::load('Net::SSLeay', 1.92) called at dev-perl/centos7/5.18.2/lib/perl5/x86_64-linux-thread-multi/Net/SSLeay.pm line 856
eval {...} called at dev-perl/centos7/5.18.2/lib/perl5/x86_64-linux-thread-multi/Net/SSLeay.pm line 858
require Net/SSLeay.pm called at dev-perl/centos7/5.18.2/lib/perl5/IO/Socket/SSL.pm line 19
IO::Socket::SSL::BEGIN() called at dev-perl/centos7/5.18.2/lib/perl5/x86_64-linux-thread-multi/Net/SSLeay.pm line 0
eval {...} called at dev-perl/centos7/5.18.2/lib/perl5/x86_64-linux-thread-multi/Net/SSLeay.pm line 0
require IO/Socket/SSL.pm called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 529
eval {...} called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 529
HTTP::Tiny::can_ssl('HTTP::Tiny') called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 1566
HTTP::Tiny::Handle::_assert_ssl('HTTP::Tiny::Handle=HASH(0x2cb2728)') called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 1062
HTTP::Tiny::Handle::connect('HTTP::Tiny::Handle=HASH(0x2cb2728)', 'https', 'domain', 9200, 'domain') called at dev-perl/centos7/5.18.2/lib/perl5/HTTP/Tiny.pm line 702
...etc...
Can't locate object method "tid" via package "threads" at dev-perl/centos7/5.18.2/lib/perl5/XSLoader.pm line 94.
Note that I had to put in a Carp::cluck
line in the XSLoader to get a stack trace.
Looking at the XS code, there are built-in assumptions that just because #ifdef USE_ITHREADS
is declared, then the threads
package is already loaded. However, that's not the case, and the XS version of threads->tid
fails.
A workaround is use threads;
in the main script, but I don't want to use threads.
Unfortunately, I can't get a stack trace of XS code, so I only know that the XS code somehow fails during the XSLoader process. But, BOOT
is calling get_my_thread_id
, and this appears to be the only case where it's trying to call threads->tid
.