Bug 1050042

+++ This bug was initially created as a clone of Bug #1044943 +++

Description of problem:

I am not really sure where to file this bug, but it seems to be the issue of Perl-DBD-Pg. When using DBD::Pg in a perl-gtk2 application, the program fails to start throwing some unexplainable error messages. The order of using the modules seem to have some effect on the bug.

The bug is always reproducible.

perl packages involved:
perl.x86_64 4:5.18.1-288.fc20
perl-Gtk2.x86_64 1.248-1.fc20
perl-Glib.x86_64 1.280-4.fc20
perl-DBD-Pg.x86_64 2.19.3-5.fc20

some one-liners to reproduce:

case 1.

perl -e 'use DBD::Pg; use Gtk2 -init;' - runs smoothly

perl -e 'use Gtk2 -init; use DBD::Pg'
Invalid version format (non-numeric data) at /usr/share/perl5/vendor_perl/Exporter/Heavy.pm line 237.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

case 2.

perl -e 'use Gtk2 -init; use Glib::Object::Subclass Gtk2::Box::,signals => {}, properties => [];' - runs

perl -e 'use DBD::Pg; use Gtk2 -init; use Glib::Object::Subclass Gtk2::Box::,signals => {}, properties => []; use DBD::Pg;'
package 'm' is not registered with Gtk2-Perl at /usr/lib64/perl5/vendor_perl/Glib/Object/Subclass.pm line 233.
BEGIN failed--compilation aborted at -e line 1

perl -e 'use Gtk2 -init; use Glib::Object::Subclass Gtk2::Box::,signals => {}, properties => []; use DBD::Pg;'
Invalid version format (non-numeric data) at /usr/share/perl5/vendor_perl/Exporter/Heavy.pm line 237.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1

--- Additional comment from  on 2013-12-19 10:49:48 GMT ---

Installing Glib 1.303 from CPAN seems to solve the issue completely.

--- Additional comment from  on 2013-12-19 13:18:01 GMT ---

Getting closer:

The two case seems to be two different issue.

case 2 (package 'm' is not registered) could be solved by upgrading perl-glib.

case 1 (invalid version format) is probably caused by LC_NUMERIC as below:

LC_NUMERIC=hu_HU.utf8 perl -e 'use Gtk2 -init; use DBD::Pg;'
Invalid version format (non-numeric data) at /usr/share/perl5/vendor_perl/Exporter/Heavy.pm line 237.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

LC_NUMERIC=C perl -e 'use Gtk2 -init; use DBD::Pg;' - runs without error even with 1.280 Glib packaged in F20.


In hungarian locale decimal comma is used instead of decimal point. I think this could be the root cause of the problem somehow...

--- Additional comment from Petr Pisar on 2014-01-06 16:11:19 GMT ---

I did not looked what's the problem, just as a remark, LC_NUMERIC has always been a problem in perl and especially in recent releases. Now, there is a huge patch set coming into upstream development tree aiming to solve it <https://www.mail-archive.com/perl5-changes@perl.org/msg37800.html>.

--- Additional comment from Petr Pisar on 2014-01-08 12:20:20 GMT ---

Regarding the LC_NUMERIC, I added some debugging into the Exporter/Heavy.pm:

# perl -e 'use Gtk2 -init; use DBD::Pg'
DBI 1,52
isvstring no
looks_like_number no
$VAR1 = '1,52';
 at /usr/lib64/perl5/vendor_perl/DBD/Pg.pm line 71.
        require DBD/Pg.pm called at -e line 1
        main::BEGIN() called at /usr/lib64/perl5/vendor_perl/DBD/Pg.pm line 0
        eval {...} called at /usr/lib64/perl5/vendor_perl/DBD/Pg.pm line 0
Invalid version format (non-numeric data) at /usr/share/perl5/vendor_perl/Exporter/Heavy.pm line 253.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

Seems like Gtk2 sets locale and then DBD::Pg passes stringified 1.52 value, hence '1,52', to DBI->VERSION() which is of course wrong.

--- Additional comment from Petr Pisar on 2014-01-08 14:55:29 GMT ---

This is smaller test case.

One has to have a locale variables exported before executing the ./test.

It does not happen when using modules from perl bundle. Something is fishy in dual-lived modules (version, Exporter) probably.

--- Additional comment from Petr Pisar on 2014-01-08 16:27:30 GMT ---

(In reply to Petr Pisar from comment #5) 
> It does not happen when using modules from perl bundle. Something is fishy
> in dual-lived modules (version, Exporter) probably.

It's caused by `version' module. version 0.9902 code as presents in Fedora 19 does not suffer from this problem.
----

The LC_NUMERIC part is caused by `version'.