Hide Forgot
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
Installing Glib 1.303 from CPAN seems to solve the issue completely.
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...
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>.
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.
Created attachment 847185 [details] Test case 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.
(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.
(In reply to Petr Pisar from comment #6) > (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. Tracked by bug #1050042.
This bug report will be used for tracking the Glib incompatibility.
perl-Glib-1.304-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Glib-1.304-1.fc20
perl-Glib-1.304-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Tried my program and the test cases with the upgraded perl-Glib, and everything works fine. Thanks.