rbutcher has asked for the wisdom of the Perl Monks concerning the following question:

Wise ones, I'm running Mandrake Linux 10 with Gnome. It comes with a whole load of perl-Gtk2 scripts pre-installed, to manage stuff like package installs and system configuration. I've switched from the pre-installed Perl 5.8.3 release to ActiveState 5.8.4 (I've used their Perl before on Win32 and I really like them so I want to stick with them). I have been careful to do a CPAN install of all the modules that are in the pre-installed 5.8.3 libs, and those files not available in CPAN I've copied over into the equivalent directory in AS 5.8.4. I've been thru the whole set of libraries to make sure I haven't missed any components.

My problem : None of the Mandrake rpm package management Perl programs work anymore, everyting else does (such as X config). The scripts won't run in terminal mode, and I have no experiece of debugging X guis. For some reason any display statements I put in don't generate any output.
So - how do I debug these Perl - Gtk2 scripts ? Would something like Komodo help ?
thanks for reading this far !
Rod

Replies are listed 'Best First'.
Re: Perl-Gtk2 debugging help needed
by Aristotle (Chancellor) on Aug 11, 2004 at 03:53 UTC

    The problem is that Mandrake have patched Gtk2-Perl specifically for some of their needs. I don't know the specifics, though. You should ask this question on the Gtk2-Perl mailing list. The Mandrake developers frequent it and will probably help you quickly.

    Makeshifts last the longest.

      Thanks Aristotle... I'll chase it up there as well.. I should have added that I tried copying all the Gtk2 stuff from the 5.8.3 distro to my 5.8.4 with the same non-result. Is it in fact OK to just copy components into my Perl "database", or does everything have to be properly installed with makefile etc ?
      Another question.. is the Perl "database" (i.e. /usr/local/ActivePerl58) self-contained ? I.e. is all the info relating to what perl modules etc I have installed contained within that directory, or does Linux keep info about perl libraries somewhetre else as well ?

      Also, my question is about perl gui debugging in general... how do the experts debug X display scripts ? I'm an amateur programmer (these days) doing community stuff, so I don't have access to work colleagues.
      thanks.. Rod

        If the modules are pure Perl, and if the Perl versions don't differ very much, then you might be able to get away with that. (It doesn't strike me as a great idea, regardless.) But Perl-GTK2 is not pure Perl. In that case you are very likely to run into native code library mismatches. I'd say "certain" instead of "very likely" in this case because you have both a Linux platform issue (what glibc did AS use to build their stuff? It's likely statically linked into their Perl, but their modules will expect it and other libraries to be just so.) and a Perl minor rev issue.

        "Even if you are on the right track, you'll get run over if you just sit there." - Will Rogers

        There is no "database". It's just a tree of files, and yes, it's self-contained because Perl doesn't use any metadata besides the directory tree and the filenames in it.

        However, as hbo explained, modules that used compiled parts, such as Gtk2 has to, may not be compatible between different versions of Perl. You can't necessarily move them around like that (though it's not out of the question).

        I'd think you can run the regular Perl debugger on Perl GUI programs; and of course, you can still use print to output diagnostic messages to the console the program was started from. In unixoid systems, there is nothing special about GUI applications.

        Makeshifts last the longest.

Re: Perl-Gtk2 debugging help needed
by ysth (Canon) on Aug 11, 2004 at 04:11 UTC
    Revert /usr/bin/perl to Mandrake's 5.8.3 and install your own /usr/local/bin/perl?
Re: Perl-Gtk2 debugging help needed
by gaal (Parson) on Aug 11, 2004 at 04:33 UTC
    Do the scripts not *have* a terminal mode, or does it just not work? This is just a suggestion for you to be able to make use of your system: try unsetting DISPLAY in the shell you run these scripts from. If they do have a console fallback mode, chances are they'll have more luck starting it that way.