Bug #132267 for Filter-Crypto: non-x86 architecture: No OpenSSL crypto library found

Mon Mar 30 01:09:46 2020 az [...] breathe-safe.com - Ticket created

Subject:	non-x86 architecture: No OpenSSL crypto library found
Date:	Mon, 30 Mar 2020 15:09:32 +1000
To:	bug-Filter-Crypto [...] rt.cpan.org
From:	Alexander Zangerl <az [...] breathe-safe.com>

this is almost a reopen of bug #86632, but for non-x86 architectures. i'm building filter-crypto on & for an arm-based single board computer that runs debian linux, and on that platform Makefile.PL doesn't look in the right places for libcrypto/libssl.*: /usr/lib/arm-linux-gnueabihf/ isn't consulted. the reporter of #86632 provided a patch that extended the general library search specifically for x86_64-linux-gnu/i386-linux-gnu but that clearly doesn't help on a non-x86 box. i think a more generic approach based on what perl -V and/or %Config report would be better. on the box in question i see these relevant bits of information: $ cat /etc/ld.so.conf.d/* # Multiarch support /usr/local/lib/arm-linux-gnueabihf /lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf # libc default configuration /usr/local/lib $ perl -V Summary of my perl5 (revision 5 version 28 subversion 1) configuration: Platform: osname=linux osvers=4.9.0 archname=arm-linux-gnueabihf-thread-multi-64int uname='linux localhost 4.9.0 #1 smp debian 4.9.0 armv7l gnulinux ' ... Linker and Libraries: ld='arm-linux-gnueabihf-gcc' ldflags =' -fstack-protector-strong -L/usr/local/lib' ... @INC: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base $ perl -MConfig -MData::Dumper -e 'print Dumper(\%Config); | fgrep lib/arm ... 'libsdirs' => ' /usr/lib/arm-linux-gnueabihf', man Config says that libsdirs '... holds the directory names aka dirnames of the libraries we found and accepted'; i think that using this in locate_lib_dir_and_file() would be a Good Idea. regards az -- Best Regards, Alexander Zangerl IT Engineer BREATHE-SAFE intelligent cabin air filtration Keeps your lungs and cabin dust free! Head Office: 37 Argon Street, Carole Park QLD 4300 Australia Western Australia: 169 Chisholm Crescent, Kewdale WA 6105 Tel: +61 7 3276 7833 M. +61 415 482 341 E. az@breathe-safe.com

Wed Dec 02 08:31:40 2020 shay [...] cpan.org - Correspondence added

On Mon Mar 30 01:09:46 2020, az@breathe-safe.com wrote: Show quoted text

> this is almost a reopen of bug #86632, but for non-x86 architectures. > > i'm building filter-crypto on & for an arm-based single board computer > that runs debian linux, and on that platform Makefile.PL doesn't look > in the right places for libcrypto/libssl.*: > /usr/lib/arm-linux-gnueabihf/ isn't consulted. > > the reporter of #86632 provided a patch that extended the general > library search specifically for x86_64-linux-gnu/i386-linux-gnu but > that clearly doesn't help on a non-x86 box. > > i think a more generic approach based on what perl -V and/or %Config > report would be better. on the box in question i see these relevant bits > of information: > > $ cat /etc/ld.so.conf.d/* > > # Multiarch support > /usr/local/lib/arm-linux-gnueabihf > /lib/arm-linux-gnueabihf > /usr/lib/arm-linux-gnueabihf > > # libc default configuration > /usr/local/lib > > $ perl -V > Summary of my perl5 (revision 5 version 28 subversion 1) configuration: > Platform: > osname=linux > osvers=4.9.0 > archname=arm-linux-gnueabihf-thread-multi-64int > uname='linux localhost 4.9.0 #1 smp debian 4.9.0 armv7l gnulinux ' > ... > Linker and Libraries: > ld='arm-linux-gnueabihf-gcc' > ldflags =' -fstack-protector-strong -L/usr/local/lib' > ... > @INC: > /etc/perl > /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 > /usr/local/share/perl/5.28.1 > /usr/lib/arm-linux-gnueabihf/perl5/5.28 > /usr/share/perl5 > /usr/lib/arm-linux-gnueabihf/perl/5.28 > /usr/share/perl/5.28 > /usr/local/lib/site_perl > /usr/lib/arm-linux-gnueabihf/perl-base > > $ perl -MConfig -MData::Dumper -e 'print Dumper(\%Config); | fgrep lib/arm > ... > 'libsdirs' => ' /usr/lib/arm-linux-gnueabihf', > > > man Config says that libsdirs '... holds the directory names aka > dirnames of the libraries we found and accepted'; i think that using this > in locate_lib_dir_and_file() would be a Good Idea. > > regards > az >

Thanks for the report, and apologies for the slow response. The previous bug that you cited actually added $prefix_dir/lib/x86_64-linux-gnu or $prefix_dir/lib/i386-linux-gnu to the search, i.e. folders within the OpenSSL installation ($prefix_dir), which is different to what you're suggesting here. If I understand you correctly, you're suggesting to add a folder such as /usr/lib/arm-linux-gnueabihf to the search, i.e. a folder that isn't within the OpenSSL installation. I'm not dead against doing that, but I feel like I'd rather not unless it's absolutely necessary (i.e. unless it's the only place that the libraries can be found) since there hasn't been any need for that so far. The previous bug reporter spoke of libs being in /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu, but then proposed a solution which actually looked in $prefix_dir/lib/x86_64-linux-gnu and $prefix_dir/lib/i386-linux-gnu. Would it work for you if the search included $prefix_dir/lib/arm-linux-gnueabihf or does it really have to be /usr/lib/arm-linux-gnueabihf ?

Wed Dec 02 08:31:40 2020 The RT System itself - Status changed from 'new' to 'open'

Wed Dec 02 18:01:07 2020 az [...] breathe-safe.com - Correspondence added

Subject:	Re: [rt.cpan.org #132267] non-x86 architecture: No OpenSSL crypto library found
Date:	Thu, 03 Dec 2020 09:00:37 +1000
To:	bug-Filter-Crypto [...] rt.cpan.org
From:	Alexander Zangerl <az [...] breathe-safe.com>

On Wed, 02 Dec 2020 08:31:40 -0500, "Steve Hay via RT" writes: Show quoted text

>If I understand you correctly, you're suggesting to add a folder such >as /usr/lib/arm-linux-gnueabihf to the search, i.e. a folder that >isn't within the OpenSSL installation.

this folder IS within the openssl installation, for modern debian(ish) systems at least: a totally normal install of the libssl-dev package on an arm box parks the ssl libraries in /usr/lib/arm-linux-gnueabihf - just like a normal install on a 64bit intel uses /usr/lib/x86_64-linux-gnu; your Makefile.PL checks the latter but not the former. Show quoted text

>Would it work for you if the search included >$prefix_dir/lib/arm-linux-gnueabihf or does it really have to be >/usr/lib/arm-linux-gnueabihf ?

these are identical in practice/with a distribution-supplied openssl: when $prefix_dir isn't handed to Makefile.PL it asks for it and defaults to /usr based on the existence of /usr/bin/openssl. -- Best Regards, Alexander Zangerl IT Engineer BREATHE-SAFE intelligent cabin air filtration Keeps your lungs and cabin dust free! Head Office: 37 Argon Street, Carole Park QLD 4300 Australia Western Australia: 169 Chisholm Crescent, Kewdale WA 6105 Tel: +61 7 3276 7833 M. +61 415 482 341 E. az@breathe-safe.com

Mon Dec 07 04:08:36 2020 shay [...] cpan.org - Correspondence added

On Wed Dec 02 18:01:07 2020, az@breathe-safe.com wrote: Show quoted text

> On Wed, 02 Dec 2020 08:31:40 -0500, "Steve Hay via RT" writes:

> >If I understand you correctly, you're suggesting to add a folder such > >as /usr/lib/arm-linux-gnueabihf to the search, i.e. a folder that > >isn't within the OpenSSL installation.

> > this folder IS within the openssl installation, for modern debian(ish) > systems at least: a totally normal install of > the libssl-dev package on an arm box parks the ssl libraries in > /usr/lib/arm-linux-gnueabihf - just like a normal install on a 64bit intel > uses /usr/lib/x86_64-linux-gnu; your Makefile.PL > checks the latter but not the former. >

> >Would it work for you if the search included > >$prefix_dir/lib/arm-linux-gnueabihf or does it really have to be > >/usr/lib/arm-linux-gnueabihf ?

> > these are identical in practice/with a distribution-supplied openssl: > when $prefix_dir isn't handed to Makefile.PL it asks for it and defaults > to /usr based on the existence of /usr/bin/openssl. > >

Thanks for the clarification. This is now fixed in commit 545421ec8f, which will be released soon in version 2.09. I haven't generalized it to use libsdirs yet. I will need to give that some thought and investigate what that looks like if it ever contains multiple directories, but thanks for the suggestion.

Mon Dec 07 16:29:38 2020 az [...] breathe-safe.com - Correspondence added

Subject:	Re: [rt.cpan.org #132267] non-x86 architecture: No OpenSSL crypto library found
Date:	Tue, 08 Dec 2020 07:29:19 +1000
To:	bug-Filter-Crypto [...] rt.cpan.org
From:	Alexander Zangerl <az [...] breathe-safe.com>

On Mon, 07 Dec 2020 04:08:37 -0500, "Steve Hay via RT" writes: Show quoted text

>Thanks for the clarification. This is now fixed in commit 545421ec8f, which wil >l be released soon in version 2.09.

great, thank you! -- Best Regards, Alexander Zangerl IT Engineer BREATHE-SAFE intelligent cabin air filtration Keeps your lungs and cabin dust free! Head Office: 37 Argon Street, Carole Park QLD 4300 Australia Western Australia: 169 Chisholm Crescent, Kewdale WA 6105 Tel: +61 7 3276 7833 M. +61 415 482 341 E. az@breathe-safe.com

Wed Dec 09 03:26:22 2020 shay [...] cpan.org - Correspondence added

Thanks again. This is now fixed in 2.09, released yesterday.

Wed Dec 09 03:26:22 2020 shay [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Dec 09 03:26:22 2020 shay [...] cpan.org - Fixed in 2.09 added