ID:               14401
 User updated by:  [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
 Status:           Open
 Bug Type:         Apache related
 Operating System: Linux i386
 PHP Version:      4.3.0-dev
 New Comment:

Well, I had hoped that the bug fix for the Apache XbitHack
would also fix our auto_prepend_file+include_path problem,
but it certainly does not.

In other words: 4.2.3 has _still_ this problem of wrong
include_path's for files loaded via auto_prepend_file.


Previous Comments:
------------------------------------------------------------------------

[2002-07-23 12:31:42] [EMAIL PROTECTED]

A short note to confirm the obvious: release 4.2.2 did
_not_ fix this problem.  It took about 24 hours after
the upgrade until it happened for the first time.

------------------------------------------------------------------------

[2002-07-18 13:39:48] [EMAIL PROTECTED]

Hmpf.  I can't tell you if the include_path issue is fixed
because I cannot even install this %*$# snapshot release.

Is this clear enough?

Our server machines are stripped down and don't have the
tools you need to build programs and RPM packages.  So we
_must_ build a RPM package on one of our development
machines, and if that RPM package passes some tests, we
can install this on our servers.  Copying the server
setup to some test server on a development machine does
not really help to be sure, because it would be difficult
to simulate the work load of the "real" server.

------------------------------------------------------------------------

[2002-07-18 13:24:05] [EMAIL PROTECTED]

Please, only ONE BUG per report, thank you.

Does the latest snapshot fix the include_path problem or not? (I'm not
interested if it doesn't build with all your configure options right
now..)


------------------------------------------------------------------------

[2002-07-18 12:53:47] [EMAIL PROTECTED]

I forgot two things:
o The above extract from config.log was created with
  snapshot 200207170600.
o In response to your comment "... some problem in your
  system" I updated the bash package to that of redhat-7.1,
  but without any effect. The bash package of redhat-7.2
  has more bugs fixed, but does not fit into a redhat-7.0
  system (incompatible changes).

After some more debugging in the last four hours I'm
pretty sure that it is _not_ a problem of our redhat
installation.

But what I did not find: How is "make" supposed to pass
the INSTALL_ROOT variable on to the php scripts that it
executes when the install-pear-installer and
install-pear-packages targets are called?

------------------------------------------------------------------------

[2002-07-18 10:38:34] [EMAIL PROTECTED]

When I said "show stopper" I meant "installation failed",
hence I don't know if this fixes the include_path problem.

The IMAP part of configure works half way: It detects that
SSL libraries are needed for c-client, but the build test
fails.  The end of config.log reads:
configure:34926: checking whether SSL libraries are needed for
c-client
configure:35086: checking whether IMAP works
configure:35119: gcc -o conftest -O2 -march=i386 -mcpu=i686 -fPIC  
-Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib conftest.c  -lcrypt -lpam
-lgmp -lgd -lttf -lX11 -lXpm -lpng -lz -ljpeg -ldb -lgdbm -lbz2 -lz
-lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl  -lcrypt 1>&5
/tmp/cc8QGtUw.o: In function `main':
/tmp/cc8QGtUw.o(.text+0x112): undefined reference to `mail_open'
collect2: ld returned 1 exit status
configure: failed program was:
#line 35094 "configure"
#include "confdefs.h"

    void mm_log(void){}
    void mm_dlog(void){}
    void mm_flags(void){}
    void mm_fatal(void){}
    void mm_critical(void){}
    void mm_nocritical(void){}
    void mm_notify(void){}
    void mm_login(void){}
    void mm_diskerror(void){}
    void mm_status(void){}
    void mm_lsub(void){}
    void mm_list(void){}
    void mm_exists(void){}
    void mm_searched(void){}
    void mm_expunged(void){}
    char mail_open();
    int main() {
      mail_open(0,"",0);
      return 0;
    }

See, there's no -lc-client.
I even did a "IMAP_SHARED_LIBADD=-lc-client ; export
IMAP_SHARED_LIBADD"
before calling configure and nothing changed.... 

I had various other build problems until I removed the
--disable-rpath option from configure (--disable-rpath was
there for "historical" reasons, read: because redhat used
it in their spec file).

The PEAR installation fails right at it's start:
$ make install INSTALL_ROOT=/var/tmp/php-root
[/bin/sh libtool command omitted for brevity]
Installing PHP SAPI module
Installing shared extensions:     /var/tmp/php-root/usr/lib/php4/
Installing PHP CLI binary:        /var/tmp/php-root/usr/bin/
Installing PEAR environment:      /var/tmp/php-root/usr/share/pear/

Warning: SAFE MODE Restriction in effect.  The script whose uid is 503
is not allowed to access /usr/share owned by uid 0 in
/home/vogel/rpm/BUILD/php4-200207170600/pear/System.php on line 235

This last message is repeated _many_ times, with some
"Warning: version_compare() expects parameter 2" messages
interspersed.

I can reproduce this in various ways (i. e. building using
rpm or doing the same "by hand"; changing configure options
did not help in any way).

If you want to reproduce: environment is redhat linux 7.0
with all relevant updates from redhat installed.  I don't
want to build with a newer redhat release, because the
target server, where the binary will get installed finally,
has redhat 7.0, too (and -- you guess it -- I cannot update
to a newer release because that's a "production" machine).

And yes, ext/pgsql in snapshot 200207170600 builds.

If you're interested, I can send you a complete log of the
rpm build via email.  I don't want to include it here
because of it's size (over 500 kByte).

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/14401

-- 
Edit this bug report at http://bugs.php.net/?id=14401&edit=1

Reply via email to