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

I'm trying to install PerlQt, and I'm in over my head, so I'm not sure whether I'm asking for the right sort of advice for that particular task. I know the Trolltech Qt library package itself is present and I know where that is (four different releases of it, in fact), so that's not the problem.

I think the problem might be that I'm trying to install this module with a version of perl that is not /usr/bin/perl. This linux machine has /usr/bin/perl, and that's fine -- I assume that there's a bunch of ubuntu sysadmin-type stuff using it, and I don't want to screw that up.

But for the apps that are going to be using Qt, I have (let's call it) /pkg/alt/bin/perl, which has been built with a separate set of libraries, has a different default @INC, etc etc. (This is a network path, and lots of different linux boxes will use it, so the apps using this version of perl don't have dependencies on various machine-local perls and libraries.)

As I struggle to figure out why Perl/Qt is not installing, I'm noticing that there are a lot of perl scripts being included with (or created by) the module distro, and these all start with #!/usr/bin/perl -- and I'm wondering...

When I start with the normal first step -- perl Makefile.PL -- is using the perl version that I want (my PATH puts /pkg/alt/bin ahead of /usr/bin), but what can I do (if anything) to make sure that all steps in the module install process invoke /pkg/alt/bin/perl instead of /usr/bin/perl ?

(As indicated above, I don't know if this is really the reason why Perl/Qt is not installing, but just on first principles, this seems like a general problem that's bound to bite me, so... Has anyone dealt with this?)

UPDATE: I have the following plan for finding and altering all the perl script files in the module distro (including, in the case of Perl/Qt, the "*.pl.in" files that are used to generate "localized" perl scripts for the installation):

find . -type f | xargs grep -l '#!/usr/bin/perl' | xargs -L 1 perl -i.orig -pe 's:#!/usr/bin/perl:#!/usr/bin/env perl: +'
or something to that effect. Alas, it doesn't solve the problem I'm still having with getting Perl/Qt installed, but... seems like a "good enough" idea. Any better suggestions?

(updated that pipeline to use "xargs -L 1" in the last step, to run perl -i on each file one at a time.)

Replies are listed 'Best First'.
Re: Module Installation Puzzle: using a non-default perl
by shmem (Chancellor) on May 30, 2009 at 16:49 UTC
    what can I do (if anything) to make sure that all steps in the module install process invoke /pkg/alt/bin/perl instead of /usr/bin/perl ?

    Move /usr/bin/perl out of the way to identify the culprit(s). Another (brute) option would be to run

    perl -pi -e 's|/usr/bin/perl|/pkg/alt/bin/perl|' `find . -type f`

    in the package directory. Maybe both? since Qt could have some perl stuff involved in the build, or your tool chain might not be fully OS-perl-clean (autoconf/automake/configure come to mind)...

Re: Module Installation Puzzle: using a non-default perl
by almut (Canon) on May 30, 2009 at 16:57 UTC
    As I struggle to figure out why Perl/Qt is not installing,...

    What is the actual error the build/install process aborts with?  What makes you suspect the problem is related to perl versions getting mixed up... any specific evidence this is happening?

      I was afraid someone would ask that... -- but seriously, thanks for asking. The last 35 lines of output from the "perl Makefile.PL" step (following ~190 lines of "checking ..." reports) look like this: So near the top I see "Note (probably harmless): No library found for -lqt-mt", and then near the bottom I see "/pkg/bin/ld: cannot find -lqt-mt" followed by "ld returned 1 exit status". So I guess the "probably harmless" comment is a bit off the mark?

      The very last line ("cannot find input file") seems like a red herring, because I checked, and smoke/qt/generate.pl.in is there (having been modified as described in the OP update).

      For that matter, the qt-3.8.8 path I'm using (via "--with-qt-dir=...") happens to have a "lib" directory that contains (among other things):

      libqt-mt.la libqt-mt.prl libqt-mt.so libqt-mt.so.3 libqt-mt.so.3.3 libqt-mt.so.3.3.8
      So, I'm sure it's just my own lack of experience with complicated library packages like Qt, but... Why is there a problem? (Let alone, what exactly is the problem?) Beats me.

      And wouldn't you know, this is the same result I got before I modified all the perl files in the distro, so in fact, it seems that (so far) the perl path issue is not the current cause of installation problem.

        g++ ... -L${exec_prefix}/lib ...

        Maybe the ${exec_prefix} hasn't been setup correctly? (Or maybe it didn't get filled in, for whatever reason — it's slightly unusual to have variables in those compile command lines...(because it makes 'post-mortem' debugging of the build process harder))   For testing purposes I would replace it with the actual qt lib directory (or add another -L... directive), and see if you can get the test program built when you manually issue the command...

        So I guess the "probably harmless" comment is a bit off the mark?

        If you need to link to something that's identified by '-lqt-mt' then it is *not* harmless, and will definitely need to be addressed. But it *is* harmless if you *don't* need to link to something that's identified by '-lqt-mt' (eg if, instead, you have to link to something that's identified by '-lqt').

        ... the qt-3.8.8 path I'm using (via "--with-qt-dir=...")


        Looking at the Makefile.PL, I'm wondering if you'd be better off specifying that location by amending $ENV{QTDIR} (in the Makefile.PL). You may also need to mess with the Makefile.PL's $MAKE. (See the INSTALL file, if you haven't already.)

        Cheers,
        Rob