in reply to Module Installation Puzzle: using a non-default perl

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?

  • Comment on Re: Module Installation Puzzle: using a non-default perl

Replies are listed 'Best First'.
Re^2: Module Installation Puzzle: using a non-default perl
by graff (Chancellor) on May 30, 2009 at 18:15 UTC
    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