What scripts..? When you install PHP from sources, any existing ini files ARE NOT TOUCHED. Did you use some RPM or what?

Noticed while trying to install roundcube webmail 0.2.0. I just tried to create a minimal testing script and didn't get it. 

One strange thing is, that if i call the script via php cli from shell, it is working. Don't know how i could debug it. roundcube using the __autoload function and all includes seems to be ok. Is there any possibility to echo the hostname, that could not be resolved if such error occur?

I am using Gentoo Linux and so installed php from source via the portage system of gentoo. I not changed the config and so used the original that is installed by gentoo. (Do not know if it is 100% identical to the original from the php source package.)

I can confirm that I'm having the same problem with php-5.2.10 on Gentoo linux.

Here it occurs with Horde Webmail, which uses the following call to change the include_path (which worked fine on any previous version of php):
> ini_set('include_path', dirname(__FILE__) . PATH_SEPARATOR . dirname(__FILE__) . '/../pear');

Because I work on RoundCube, I double-checked this bug submission.

Just compiled PHP 5.2.10 from source with this:

./configure --with-mysql  --enable-fastcgi --enable-force-cgi-redirect
make

And then put the "sapi/cgi/php-cgi" into the webserver as the fcgi 
binary it uses to serve PHP to test it. And, absolutely no issues.

It seems to me like the Gentoo packages are borked. I suggest you guys 
verify that it works for you when you compile PHP from source.

I don't think we are shipping any intrusive patches here at gentoo anymore, and those we do ship haven't changed for some time.
Also, I'm using roundcube without problems on one of my machines with the latest php and another dev just told me he's using horde without problems.
Please retry with a vanilla php build (tarball from php.net)

Same problem with the latest snapshot.

But I got the problem. Problem with roundcube is fixed if I ./configure laltest snapshot (or 5.2.10) without --with-curlwrappers (means --without-curlwrappers).

With 5.2.9 it worked with --with-curlwrappers. Maybe it is a side condition of the stream_wrapper in include (change from 5.2.9 to 5.2.10). Would be nice if it is fixable :)

Thanks
Alexander

Same problem as in bug #48603 then.

Quote from that bug:

> Seems to be caused by the changes to curl to avoid serving file://
> urls when open_basedir or safe_mode are enabled combined with the
> "--with-curlwrappers" option.

But my config contains that:

;open_basedir =
safe_mode = Off


Alex

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.