php-install Digest 17 Mar 2003 15:14:25 -0000 Issue 1293

Topics (messages 10348 through 10350):

Re: Help! Problem building PHP 4.3.1 with Apache 1.3.27 on Solaris 2.8
        10348 by: Bob Boeninger

Re: Compile error Apache 1.3.27 + PHP 4.3.0
        10349 by: Dieter Müller

includes PHP 4.3.0 and Solaris
        10350 by: Jean-Pierre Gallou

Administrivia:

To subscribe to the digest, e-mail:
        [EMAIL PROTECTED]

To unsubscribe from the digest, e-mail:
        [EMAIL PROTECTED]

To post to the list, e-mail:
        [EMAIL PROTECTED]


----------------------------------------------------------------------
--- Begin Message ---
I think I figured out the problem I was having, wth one of the two options
for building Apache with PHP, the one involving the use of apxs. There seems
to have been a bug in the 'configure' program for PHP (4.3.1), is what I
think at the moment anyway: some of the args passed to the call of 'apxs'
were in the form of 'CFLAGS' rather than '$CFLAGS'.
I wonder though, why no one else seems to have had this problem.

Over and out,

Bob Boeninger



"Bob Boeninger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello,
>
>
>
>    Didn't see either of these two problems I'm having building PHP 4.3.1
> with Apache 1.3.27 on Solaris 2.8:
>
>
>
> I've tried two recommended ways of building Apache with PHP:
>
>
>
> ...
> 5.  cd apache_xxx
> 6.  ./configure --prefix=/www --enable-module=so
> 7.  make
> 8.  make install
>
> 9.  cd ../php-xxx
> 10. ./configure --with-mysql --with-apxs=<correct path>/apxs
> 11. make
> 12. make install
> ------------
>
>
>
> When I get to step 10: ./configure --with-mysql --with-apxs=<correct
> path>/apxs
>
>
>
> I get the error:
>
>
>
> Configuring SAPI modules
>
> checking for AOLserver support... no
>
> checking for Apache 1.x module support via DSO through APXS...
>
> APXS: /opt/apache_March_13_2003/bin/apxs
>
> CFLAGS: -g -O2
>
>
>
> Sorry, I was not able to successfully run APXS.  Possible reasons:
>
>
>
> 1.  Perl is not installed;
>
> 2.  Apache was not compiled with DSO support (--enable-module=so);
>
> 3.  'apxs' is not in your path.  Try to use --with-apxs=/path/to/apxs
>
>
>
> The output of /opt/apache_March_13_2003/bin/apxs follows
>
> Usage: apxs -g [-S <var>=<val>] -n <modname>
>
>        apxs -q [-S <var>=<val>] <query> ...
>
>        apxs -c [-S <var>=<val>] [-o <dsofile>] [-D <name>[=<value>]]
>
>                [-I <incdir>] [-L <libdir>] [-l <libname>] [-Wc,<flags>]
>
>                [-Wl,<flags>] <files> ...
>
>        apxs -i [-S <var>=<val>] [-a] [-A] [-n <modname>] <dsofile> ...
>
>        apxs -e [-S <var>=<val>] [-a] [-A] [-n <modname>] <dsofile> ...
>
> configure: error: Aborting
>
> --------------------
>
>
>
> So, none of these 3 possibilities seem to pertain in my case. And how
should
> it be complaining about the way apxs is being called, since this should be
> included in the configure file correctly, one would think.
>
> ============
>
>
>
> The other recommended way of building everything is:
>
>
>
> cd apache-1.3.27
>
>
>
> ./configure --prefix=/u1/apache_March_11_2003
>
>
>
> That's all for apache for the moment. Now set up PHP:
>
> -------------------
>
> PHP:
>
>
>
> cd php-4.3.1
>
>
>
> ./configure --enable-discard-path                                       \
>
>         --prefix=/u1/apache_March_11_2003/php/                         \
>
>         --with-apache=/u1/apache_March_11_2003/build/apache_1.3.27     \
>
>
>
> gmake
>
>
>
> gmake install
>
>
>
> Then we go back and do another, fancier configure of apache:
>
>
>
> ./configure                                             \
>
>         --activate-module=src/modules/php4/libphp4.a    \
>
>         --enable-module=php4                            \
>
>         --prefix=/u1/apache_March_11_2003
>
>
>
> make
>
> make install
>
> ----------
>
>
>
> It's during this last 'configure' where I get the following error:
>
> ...
>
> + checking sizeof various data types
>
>  + doing sanity check on compiler and options
>
> ** A test compilation with your Makefile configuration
>
> ** failed.  The below error output from the compilation
>
> ** test will give you an idea what is failing. Note that
>
> ** Apache requires an ANSI C Compiler, such as gcc.
>
>
>
> ======== Error Output for sanity check ========
>
> cd ..; gcc  -DSOLARIS2=280 `./apaci`     -o helpers/dummy
>
lpers/dummy.c   -L/usr/ucblib -L/afs/.slac.stanford.edu/package/gcc/sun4x_56
>
/gcc-2.95.3/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3 -L/usr/oracle/lib -Lmodu
> les/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -export-symbols
>
pt/apache_March_11_2003/build/php-4.3.1/sapi/apache/php.sym   -L/usr/ucbli
>
b -L/afs/.slac.stanford.edu/package/gcc/sun4x_56/gcc-2.95.3/lib/gcc-lib/spar
>
c-sun-solaris2.6/2.95.3 -L/usr/oracle/lib   -lcrypt -lresolv -lm -ldl -lnsl
> -lsocket  -lgcc -lcrypt -lnsl -lsocket -lgen -ldl -lsched -lclntsh -locijd
bc
>
8 -lnsl -lsocket -lgen -ldl -lsched -lclntsh   -lsocket -lnsl -lpthread -lex
> pat -ldl
>
>
>
> ld: fatal: file
> /opt/apache_March_11_2003/build/php-4.3.1/sapi/apache/php.sym: unknown
file
> type
>
>
>
> ld: fatal: File processing errors. No output written to helpers/dummy
>
> collect2: ld returned 1 exit status
>
> *** Error code 1
>
> make: Fatal error: Command failed for target `dummy'
>
> ============= End of Error Report =============
>
>
>
> What's with this silly, innocuous 'php.sym' file? It's a one-line ASCII
> file; nothing to it. Of course I have gcc, which works fine lots of
places.
>
>
>
>  By the way, this procedure works fine with PHP 4.2.1 instead of 4.3.1,
> which I'm trying to use here.
>
>
>
> Why can't this just work properly instead causing so much grief?
>
>
>
> Would anyone have any idea on what these two problems might be about?
>
>
>
> Thanks,
>
>
>
> Bob Boeninger
>
> [EMAIL PROTECTED]
>
> ~
>
>
>



--- End Message ---
--- Begin Message --- Solution is very simple ;-)


configure PHP 4.3.1 without "--enable-versioning"



like



CFLAGS='-O2 -I/usr/local/openssl/current/include' \ ./configure \ --with-apache=/usr/src/tars/apache_1.3.27 \ --with-mysql=/usr/local/mysql/current \ --with-zlib \ --with-ftp \ --with-pdflib=/usr/local \ --with-freetype-dir=/usr \ --with-gd \ --enable-gd-native-ttf \ --enable-gd-imgstrttf \ --with-jpeg-dir=/usr/local/lib \ --with-png-dir=/usr/local/lib \ --with-tiff-dir=/usr/lib \ --enable-track-vars=yes \ --enable-url-includes \ --enable-sysvshm=yes \ --enable-sysvsem=yes \ --enable-bcmath \ --enable-inline-optimization \ --with-config-file-path=/usr/local/apache/1.3.27/conf


--- End Message ---
--- Begin Message --- Hi,

I manage a web server with many hosted virtual servers. I am experiencing problems with includes in PHP 4.3.0 under Solaris, and I can't upgrade my server. I think it has something to do with getcwd() not working on Solaris if a component of the path is not readable by the server, which is the case for most virtual server document roots.

Most errors are with PHP codes which include things from the parent directory (..), which is in 'include_path'.

Look at this test:

tests/
 |- inc
    |- inc.txt              include OK
 |- mydir/
    |- testinclude.php      <? echo 'getcwd:', getcwd(), '<BR>';
                            include ('inc/inc.txt'); ?>

I have two httpd working, with the same config file except the port number (the server on 8088 loads the 4.3.0 version of libphp.so).
safe_mode is off. Include_path is '.:../:../../' for 4.2.1.


With PHP 4.2.1,
  <http//my.server.com/tests/mydir/testinclude.php> works OK.
With 4.3.0,
  <http//my.server.com:8088/tests/mydir/testinclude.php> gives:
  Failed opening 'inc/inc.txt' for inclusion
  (include_path='.:../:/usr/local/php-4.3.0/lib/php')
   in /usr/local/www/docs/www/tests/mydir/testinclude.php on line 2

getcwd() returns nothing in both cases, since a directory is -rwx--x--x
On Solaris, getcwd() needs "r" access to _all_ directories of the path, otherwise you get (from "man getcwd"):
EACCES A parent directory cannot be read to get its name.
(It's not a bug, but a feature; seems strange to me).


include '../inc/inc.txt' does not work either. The only way I found to get it work in PHP 4.3.0 is "chmod o+r" on every component of the dir path (this way, getcwd() returns the right value, and include works). It looks like PHP resolves the pathname itself, using getcwd(). Due to this feature of Solaris, in my opinion, it's not a good idea to rely on this function to get a real pathname.

I can't tell the webmasters to "chmod o+r" their directories. What else can I do to be able to upgrade my server?


--- End Message ---

Reply via email to