Global symbol "$releaseid"...

  • John Haskey

    John Haskey - 2011-05-27

    Hi, I'm trying to set up lxr 0.9.9 on FreeBSD with Perl 5.10.1 and apache22.  I think I've configured things correctly but when I hit http://myhost/lxr/source I get:

      Global symbol "$releaseid" requires explicit package name at /usr/local/share/lxr/source line 93.

    and a lot more in my apache httpd-error.log

    I'm not a perl wizard.  Did I miss something in the setup or make an obvious error somewhere?  Thanks!

  • Andre-Littoz

    Andre-Littoz - 2011-05-28


    $releaseid is a global variable defined in and imported with a sentence "use qw(:html);" near the beginning of the file. This is all you need to reference that variable without qualification. Is there any complaint about access to file in your httpd-error log?

    A possible cause could be the way the library are searched under FreeBSD (I must admit I'm not at all familiar with this OS). In that case, check file which contains the location of the libraries. To evolve towards a more automatic (or blind) installation procedure under Linux, I opted for a relative form of the library paths in release 0.9.9. Try to replace these with an absolute form, i.e. '.' with '/usr/local/share/lxr' (don't forget the single quotes) and './lib' with '/usr/local/share/lxr/lib'.

    Feedback appreciated. have a good day!

  • John Haskey

    John Haskey - 2011-05-31

    Hi, and thanks for the reply.  Yes, I've looked at and currently have the full path to the lxr directory and the lib directory as you mention.  The only error messages in httpd-error.log relate to the $releaseid variable (well, there is a warning about the -T switch but it's just that, a warning.  What's the easiest way to ensure that it's finding

  • John Haskey

    John Haskey - 2011-05-31

    I've poked at it some more and it's marginally working.  I switched to .htaccess_cgi.  With apache22 it works better using Script instead of ScriptAlias (at least on this system)  With ScriptAlias is was trying to interpret everything as a script including the valid-html401.png file.  This apache22 install also didn't have the icons folder in the right place.  A soft link fixed that.  I'm getting further…  :-)

  • John Haskey

    John Haskey - 2011-06-03

    Final post for the moment, the last thing I changed was due to "Insecure $ENV{PATH} while running with -T switch" coming from search at around line 152 where the line $ret = `$swishcommand`; is found.  Using a hint from the web I put this code in a block by itself and created a 'local' environment setting PATH and BASH_ENV.  Is/was this the proper way to handle this?  Anyway, up and running now with a manually updated source tree.  Thanks for your attention.

  • Andre-Littoz

    Andre-Littoz - 2011-06-03

    Answer is yes and no: "Insecure …" is a message related to possible security leaks in Perl. Every data comming from outside your program is considered a potential threat (Perl allows evaluation of any data as a program, therfore you can inject malicious procedures inside a program). You can use a trick to laundry the incoming data.

    I have no time today (and tomorrow too) to go thoroughly into the problem but I promise to do so as soon as my son's wedding is over.

    Stay tuned.

  • John Haskey

    John Haskey - 2011-06-03

    Just to summarize:

    The line ( ~153) that read my $ret = `$swishCommand`;

    I replaced with this code:

      my $ret = "";
      local $ENV{"PATH"} = "/bin:/usr/local/bin:/usr/bin";
      local $ENV{"BASH_ENV"}="";
      $ret = `$swishCommand`;

    and the errors in httpd-error.log went away.  Remember I'm still running as cgi and not mod-perl.  With mod-perl I still
    get the problem with $releaseid.

  • Andre-Littoz

    Andre-Littoz - 2011-06-06

    You did the right thing to "untaint" $ENV{"PATH"}. You were also overcautious with "local". You could as well drop it and the change is persistent and available in any other procedure (at least, it does no harm in LXR).

    When reviewing the code, I noted that the original implementors did not code consistently the searches with glimpse and swish. If you read glimpsesearch a few lines above, you'll see the magic untainting line. Maybe, swish-e is less used than glimpse and the error shows up less frequently. Anyway, I corrected that a while ago and transfered the "untainting" code in (sub httpinit) so that it is done early and once for all. It will be available as soon as I release 0.9.10.

    I investigate for access. My Apache is 2.2.17, which seems to be same version as yours (22 family). It works for me both as CGI or mod_perl. My Perl is 5.12.3. Difference may lie here. Looking through the strings in mod_perl, I found it could be level 2.0.4. Check yours. If your versions are the same (or very close), we'll have to see the differences between Linux and FreeBSD.

    Since some features changed between Perl 5.10 and 5.12, you could get a bug in "include" processing. Let me know. If that is the case, I'll try to modify the statements in a backward compatible way. This has already be reported, see the trackers. If too many people are affected, I'll be compelled to have a more conservative approach.

  • John Haskey

    John Haskey - 2011-06-06

    Hi, thanks again for looking into these issues.  I too am running Apache 2.2.17, my Perl is 5.10.1, mod_perl 2.0.4.  Just FYI…

  • Andre-Littoz

    Andre-Littoz - 2011-06-19

    I am very upset with this no-access issue. If it is related to library designation, try to add to the following line after …/lib:

    , '/usr/local/share/lxr/lib/LXR'

    This is in case Perl's implementation on FreeBSD does not recursively explore  the library paths. If it solves the issue, I'll add a caveat in the installation instructions.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks