I'm running Perl v5.16.3 on Red Hat GNU/Linux 7.9.

OUCH! Perl 5.16 has been End-Of-Life without any security or stability updates for nearly a decade now. You REALLY need to upgrade to a newer Perl version.

Are you running the system Perl provided by Redhat? This is generally a bad idea for user provided scripts (e.g. anything that is NOT maintained by the Linux Distribution itself).

Most distributions also provide a number of packages to install extra Perl modules required by other packages from the distribution. If you mess with those (install stuff from CPAN, especially updated modules), you can easily break your operating system. This goes for pretty much all scripting languages, BTW, one of the reason NodeJS, Python, etc all use some variant of "install stuff into the users home directory".

From the error message i suspect that a mix-up between CPAN installed stuff and Redhat provided packages has indeed occured.

There are quite a few ways to use a user-provided perl installation. The easiest is probably Perlbrew. Personally, i'm a more oldschool hands-on guy that likes to finetune things, using the classic install instructions from https://www.cpan.org/src/ and a handful of complicated bash+perl scripts to finetune things on a per-project basis.

But as a start, i'd recommend using Perlbrew to install an up-to-date Perl 5.38 into your home directory and installing all the required modules ONLY from cpan. That way, we can be sure you have a reasonably clean installation and use that to help you trace any other problems that might occur.

With an ancient, unsupported Perl version that may or may have not been messed with by the Linux distributor and/or admins of the server, it's really hard to tell what the root cause of your problem is.

Yes, I'm using the Perl that is managed by Red Hat for 7.9 version of their OS.

rpm -qf /bin/perl
perl-5.16.3-299.el7_9.x86_64
[download]

Red Hat for 7.9 version of their OS

Just in case you were unaware, that support from RedHat will cease on the 30th of June 2024 - ie. less than a year from now. Unless your organisation wants to pay for ELS you should be working on an exit/upgrade strategy today.

---

🦛

Uhm, i wouldn't exactly say that a one-decade-out-of-support software is "managed", i'd certainly look into upgrading the whole system to more modern software for security reasons.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP

It means the module it finds is part of an install of Template-Toolkit 2.24, while the associated DLL it finds is part of an install of Template-Toolkit 3.101.

You must have an "intersting" @INC.

I managed to get Bugzilla working on another host.

Broken host:

$ grep '[$]VERSION' /usr/lib64/perl5/vendor_perl/Template.pm
our $VERSION = '2.24';

$ grep '[$]VERSION' /usr/local/lib64/perl5/Template.pm
our $VERSION = '3.101';
[download]

Working host:

$ grep '[$]VERSION' /usr/lib64/perl5/vendor_perl/Template.pm
grep: /usr/lib64/perl5/vendor_perl/Template.pm: No such file or direct
+ory

$ grep '[$]VERSION' /usr/local/lib64/perl5/Template.pm
our $VERSION = '3.008';
[download]

Now I need to determine why this difference exists and if it the reason why Bugzilla is broken.

On the broken host you have 2 versions of Template installed - an ancient one from the O/S package and a newer one from CPAN. On the working host you do not have the ancient one. Tentative solution: remove the O/S package from the broken host via yum (after backing everything up first, of course).

---

🦛

Thanks. That was my guess too. So I ran yum remove perl-Template-Toolkit. The XS object version issue no longer appears. Now I get to chase the next issue:

Base class package "Template::Base" is empty.
[download]