Re: [Lxr-dev] Further testing

[Malcolm B. <ma...@br...>]

Jan-Benedict Glaw wrote:
> For those very old Linux kernels (v 0.01, 0.10, 0.11, 0.12) I've
> adden another "architecture", noarch. /asm-noarch/ gets mapped
> back to pure /asm/ because these old kernels had nothing else
> than i386 support. Loading pages sometimes gives me errors like

> ** Fatal: Can't locate LXR/Lang/Generic.pm in @INC (@INC contains: /
> usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /
> usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/
> lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/
>              /etc/apache/lib/perl) at (eval 20) line 3.
> 
>  ** Fatal: Can't locate object method "new" via package "LXR::Lang::
> Generic" (perhaps you forgot to load "LXR::Lang::Generic"?) at (eval
>                              21) line 1.
> 
> ** Fatal: Unable to create LXR::Lang::Generic Lang object, at /home/
>                data/lxr-cvs/lib/LXR/Common.pm line 84.

This looks very much like the error that's caused by not being able to
find/load a library.  Was this error message created before/after you
re-added the "lib" line?

I've seen this message both with and without that line, and I have to
say it confuses me, since I can't work out why the library is not found.

<snip>

> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing
> 
> ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c
> 
> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing
> 
> ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c
> 
> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing

No idea about this one - though obviously it is now finding the library,
which is bizarre.

> The third load then looks better:
> Does anybody have some hint how to get the complete page just at
> the first shoot?

Nope - these are the sort of problems that not finding the libraries
seem to cause, but as you say, only on the first time through.  As the
scripts are running under mod_perl, perhaps the changes to @INC are
being stored from invocation to invocation, but for some reason are not
happening early enough to enable the loading on the first path.

I'm afraid mod_perl/Perl gurus are going to be needed for this one - any
takers?

Malcolm