in reply to Re: XSLoad::load calls itself?
in thread XSLoad::load calls itself?

Good point.

Since the "use XSLoader ();" statement isn't dieing, I suspect XSLoader is already loaded (it is also a core module).

Oh! I just had an idea. One simple explanation would be if @INC included "/usr/lib64­/perl5/ven­dor_perl/5­.8.8/x86_6­4-linux-th­read-multi­/APR" before the path where the XSLoader module is. Then "use XSLoader ();" would load the XSLoader.pm from the APR::XSLoader module.

Note that @INC should not contain "/usr/lib64­/perl5/ven­dor_perl/5­.8.8/x86_6­4-linux-th­read-multi­/APR" at all.

So the next step I'd recomment is reporting the value of $INC{"XSLoader.pm"}.

- tye        

Replies are listed 'Best First'.
Re^3: XSLoad::load calls itself? (use)
by brent.allsop (Acolyte) on Aug 29, 2007 at 16:57 UTC
    Folks, Oh, XSLoader and APR::XSLoader are different. That explains a lot. I did a cpan install of XSLoader, and evidently I didn’t have that since it installed right? But it is still getting the same undefined XSLoader::load error.
    You can’t do a print of $INC{"XSLoader.pm"} since it doesn’t compile right? But I did a use glip::wad; in startup.pl to cause the below error dump of @INC:
    But there is no APR anywhere in there right? It must be getting it some where since, as you said, the use XSLoader is not dieing right, even before I installed it?
    So this $INC{"XSLoader.pm"} doesn’t really work right? Since INC is an array? How do you find out what value it is finding and using?
    Thanks
    Brent Allsop
    @INC (@INC contains: /usr/local/webtools /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/Apache2 / +usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/Bundle /u +sr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/p +erl5/site_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/ +perl5/site_perl/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib64/per +l5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi /usr/lib6 +4/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi /usr/lib/ +perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr +/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 +. /etc/httpd)

      perlvar covers both @INC and %INC. Did you even try? Or did you just assume it wouldn't compile?

      "/usr/lib64­/perl5/ven­dor_perl/5­.8.8/x86_6­4-linux-th­read-multi­/Apache2" looks suspicious to me. And, indeed, there is an Apache2::XSLoader module.

      - tye        

      `
        Tye,

        Yes I did try printing out $INC{"XSLoader.pm"} but got an undefined value or something.

        But anyway, I removed the Apache2 line that looked suspicious to you, and that resolved that issue. That was great! Thanks so much for the help!

        So, now I can get Apache (and startup.pl) to start just fine. But when I try to execute my index.asp page, it can't find a pm file it depends on. And it prints out a new value of the @INC array.

        If you look back at my previous post, you see that the @INC printed out when there is an error in startup.pl clearly has this right at the top:

        /usr/local/webtools

        which is where this pm file is located.

        But the @inc array printing out with this asp compile error is different, and doesn't have the webtools value in it?

        Why is it now different? What is the deal? And how do I get a value into this different @inc array that is evidently used when compiling asp pages?

        Thanks!

        Brent Allsop