[FR] support using Perl versions installed elsewhere but `/usr/bin/perl`

[albenstein]

We are using mirdeep2 on our HPC system. When we try to call mirdeep2.pl, it gives this error:

Perl v5.35.7 required--this is only v5.26.3, stopped at /opt/ohpc/pub/compiler/perl/5.36.0/lib/5.36.0/File/Copy.pm line 10. BEGIN failed--compilation aborted at /opt/ohpc/pub/compiler/perl/5.36.0/lib/5.36.0/File/Copy.pm line 10. Compilation failed in require at /opt/ohpc/pub/apps/mirdeep2/0.1.3/bin/miRDeep2.pl line 25. BEGIN failed--compilation aborted at /opt/ohpc/pub/apps/mirdeep2/0.1.3/bin/miRDeep2.pl line 25.

Could you please help on this issue?

[mschilli87]

AFAICT, the error message states that miRDeep2 requires Perl version 5.35.7 (or higher) to run while your HPC system provides version 5.26.3 only. Since 26 < 35, I'd say you'll have to (ask your administrator to) update your Perl installation to a newer version before you can run miRDeep2. Not sure what additional help you are hoping to find here. 🤷

[albenstein]

miRDeep2.pl using perl 5.36.0.

[albenstein]

perl --version

This is perl 5, version 36, subversion 0 (v5.36.0) built for x86_64-linux

---

edit (@mschilli87): Fixed formatting.

[mschilli87]

@albenstein:

miRDeep2.pl using perl 5.36.0.

I see... 🤔 How exactly did you install miRDeep2?

[albenstein]

We installed miRDeep2 with manual installation which is written on README.md

[mschilli87]

@albenstein:

We installed miRDeep2 with manual installation which is written on README.md

Thank you for following up and providing the necessary information. I'll have to hand over to @Drmirdeep regarding a possible solution though.

---

PS: You might want to give the install.pl script a try though. Could be helpful to understand if it's a problem with your system or the manual installation documentation.

[Drmirdeep]

Seems to be related to the copy.pm module. I cannot help with it. This is related to the Perl installation you have on your machines.

[albenstein]

On perl e-mail group they said this: So, are you using the correct path for the latest version of perl? It seems you have the right perl and File::Copy installed, but your program is using the old version. How can we see miRDeep.pl uses which version of perl?

[albenstein]

I figured out the problem. On mirdeep2 program there is a line at the begining calls perl. I changed this line with perl5.36.1 with absolute path. Program starts to run. Thanks for help

[mschilli87]

@albenstein: Are you referring to the #!/usr/bin/perl line? If so, you should be able to override it without the need to modify miRDeep2.pl by calling perl5.36.1 $(which miRDeep2.pl) instead of miRDeep2.pl.

---

@Drmirdeep: We could consider replacing the #!/usr/bin/perl shebang by #!/usr/bin/env perl to always use the same perl binary as running perl from the shell would. Any thoughts?

---

edit: @albenstein: Do you mind sharing the output of /usr/bin/perl --version to confirm this is indeed the culprit?

[albenstein]

/usr/bin/perl --version

This is perl 5, version 26, subversion 3 (v5.26.3) built for x86_64-linux-thread-multi (with 57 registered patches, see perl -V for more detail)

[albenstein]

I've just changed shebang with #!/usr/bin/env perl . Program runs again.

[albenstein]

mapper.pl has same issue. After I've changed shebang, it started to run.

[mschilli87]

@albenstein: Thx for following up. Yes, if we want to support running miRDeep2 in a multi-/non-system-perl environment, we'd have to update the shebang across all of miRDeep2's perl scripts. That decision lies with @Drmirdeep though.

---

@Drmirdeep: I'd be in favor of switching to /usr/env. Nowadays there are probably more systems without /usr/bin/perl than there are such without /usr/bin/env. One of the few places where this might require downstream adjustements is packagig for GNU Guix as they rewrite the shebang lines to use /gnu/store/.../perl instead of /usr/bin/perl, but I'd happily contribute the corresponding patch to them with the next miRDeep2 release. Every standard Linux/MacOS system should be unaffected by this change since /usr/bin/env perl will just be replace itself by /usr/bin/perl anyhow. Your call.

Leaving this issue open as a reminder.

[Drmirdeep]

Seems to be an edge case occurring due to having non canonical Perl environments/multiple perl versions installed 🤷🏼‍♂️ changing it to /usr/bin/env perl may be a solution. However, since it seems to be a versioning problem the users have to make sure that the 'demanded' version is always the one found by 'env'. So a simple patch could be applied.

To have something consistent accross environments on an HPC you would have to use a vritual env and clone it to all nodes.

Anyhow, multiple ways to solve it.

To replace perl by env you could use this command in your mirdeep2/bin directory

for i in `grep -l /usr/bin/perl *`;do 
      perl -pi.bak -e 's/bin\/perl/bin\/env perl/g' $i
done