ID:               22174
 User updated by:  [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Feedback
+Status:           Open
 Bug Type:         PHP options/info functions
 Operating System: OpenBSD 3.1-stable
 PHP Version:      4.3.0
 New Comment:

I'm already using libtool 1.4.3, so it's not that.

I last rebuilt PHP from CVS yesterday morning and it was all ok. Up
until switching to 4.3 release, I had never seen a problem with my ini
file. Very strange I know...

The compile problem seems to be something to do with gm4? It dumps lots
of pages relating to bison? I'll do a more accurate bug report if it's
still there tomorrow.


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

[2003-02-11 15:18:14] [EMAIL PROTECTED]

I upgraded the libtool version in CVS and we now require
libtool 1.4.3. Just install that and the compile problems 
should be gone..(and update your cvs checkout since I just fixed some
other issue that came with the libtool upgrade)

About the php.ini location..you're sure the bug is not present in the
PHP_4_3 branch? 


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

[2003-02-11 14:15:42] [EMAIL PROTECTED]

This problem seems to take many forms, as evidenced by the bug
database, but from all the entries I have read, none seems quite like
what I'm seeing.

I've been using 4.3 from CVS since about last June, and set up my
php.ini around then, and I have not really touched it since (not the
problem). I've stayed with CVS versions ever since, until today. I
started having a compilation problem with the cvs version (Separate
problem), but I still needed to rebuild PHP so I grabbed the release
4.3.0. This compiled (using the same configure I've been using all
along) with no problems so I installed it and got file not found errors
all over. phpinfo reveals that everything is at defaults (include_path
at default value was causing my errors), i.e. php.ini is being ignored.
I recompiled several times specifying many different locations for
php.ini, but none worked.

So now it looks like maybe a permissions problem, Except that the
php.ini is the same file that has been working for many months with cvs
versions up until yesterday - this is the first time I've tried using a
release version. Whatever, all permissions look fine - the www user has
no trouble reading the file.

I thought perhaps the format or content of the ini file had changed, so
I built a new one with my settings in from php.ini-recommended. Made no
difference, but was probably a good idea anyway.

Eventually I found the bug report about php preferring /php.ini over
the compiled in location, so I copied my old php.ini there and it did
indeed pick it up (a temporary workaround), So now I know there's
nothing wrong with what's in either my old or new php.ini files (I
don't seem to be seeing the current open bug about php.ini based on
recommended not working).

So the only remaining variable is that I'm using 4.3.0 release, and not
a CVS version. Everything else is identical. I can only surmise that it
must be a release version bug. I would like to confirm this by
compiling a CVS version and have it work, but as I mentioned, it's not
compiling for me right now, so I can't test that.

Just for good measure, here's my configure:
./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr/local
--enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-bz2
--with-zlib --with-openssl --with-gettext --with-ldap --with-mhash
--disable-overload --enable-sockets --with-mcrypt --enable-sysvshm
--enable-pcntl --with-config-file-path=/var/www/conf --enable-mbstring
--with-pear=/usr/local/lib/php --enable-bcmath --enable-gd-native-ttf
--enable-gd-imgstrttf --with-freetype-dir=/usr/local

Extracts from phpinfo:
With /php.ini:
Configuration File (php.ini) Path /php.ini

Without /php.ini, (ini in specified place)
Configuration File (php.ini) Path /var/www/conf/

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


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

Reply via email to