Discussion in 'Bug Reports' started by pcguru, Mar 20, 2006.

  1. pcguru

    pcguru Member


    I have two servers online with litespeed on them, one free version, and one enterprise. Neither of the two hosts put anything in the $_SERVER['HTTP_ACCEPT_LANGUAGE'] variable with PHP, nothing at all.

    Apache sets it correctly to "sv" for my browser.

    I need this to work, what should I do?
  2. mistwang

    mistwang LiteSpeed Staff

    It is a bug in LSAPI code, if you build your own PHP binary, you can fix it by changing two line of code at beginning of "lsapilib.c".
    search for "HTTP_ACCEPT_LANG", change it to "HTTP_ACCEPT_LANGUAGE", then serch "11, 19, 20, 16,", change "16" to "20", then rebuild your lsphp binary.

    If you are not comfortable with code changes, please wait for next LSAPI code release.
  3. pcguru

    pcguru Member

    It worked like a charm as usual mistwang. :D

    After fixing this and trying to enable GD for PHP as well I ran into the next problem, PHP:s extensions do not configure properly because the configure script gets confused on 64-bit machines where /usr/lib64/lib doesn't exist. Solved by . Could be nice to know if someone asks. 8) Don't know why the PHP-freaks haven't fixed this, it's an old bug report.
  4. xing

    xing LiteSpeed Staff

    PHP 5.1.2 and its extensions compile correctly under CentOS 4.2 x86_64.

    Perhaps the the problem got fixed in the late php releases but didn't get backported to the earlier ones.

    Which php version were you trying to build extensions for on 64bit distro and failed? We definitely would like to keep track of all the weird php problems that litespeed users find and the fixes for them as the forums get as much php questions as litespeed ones. =)
  5. pcguru

    pcguru Member

    We're using 4.4.1, should upgrade to 4.4.2 in the future. Changelog for 4.4.2 has no info about this configuration error so I don't think it has been fixed.

    Server OS is SLES9.
  6. pcguru

    pcguru Member

    Not fixed

    Just wanted to say that the issue with 64-bit library directories in PHP 4.4.2 has not been fixed. GD still fails when configuring, complaining about "configure: error: libpng.(a|so) not found." etc. It will likely not be fixed since it works in PHP 5.

    Here's the guide to fix it since the original site is not available anymore (

    1. Add the following lines to
    dnl Support systems with system libraries in e.g. /usr/lib64
    [  --with-libdir=NAME     Look for libraries in .../NAME rather than .../lib],
    [PHP_LIBDIR=$withval], [PHP_LIBDIR=lib])
    Add them right at the beginning, after 'dnl AC_PROG_CXXCPP'.

    Keep in mind we want to run ./configure --with-libdir=lib64 and have it cause ./configure to look for libraries in, for example, /usr/lib64 rather than /usr/lib.

    2. Edit the config.m4 file for the extension you want to compile (for example, ext/gd/config.m4), and change 'lib', when used to indicate a directory part such as /usr/lib, into '$PHP_LIBDIR'. You have to look at all instances manually; automated replacing for example might replace with $ which is not what you want.

    You can download a fixed config.m4 for GD in PHP 4.4.2 here:

    3. Once you're happy and ready to go, type: autoconf to generate your new ./configure

    4. Run ./configure but make sure you add --with-libdir=lib64.
  7. mistwang

    mistwang LiteSpeed Staff

    Thank you for your guide to fix this issue. You can post it in our Wiki if you want. :)

Share This Page