Edit report at https://bugs.php.net/bug.php?id=65497&edit=1
ID: 65497
User updated by: cmbecker69 at gmx dot de
Reported by: cmbecker69 at gmx dot de
Summary: All tests are failing
-Status: Feedback
+Status: Open
Type: Bug
Package: *Compile Issues
Operating System: Cygwin
PHP Version: 5.5.2
Block user comment: N
Private report: N
New Comment:
The test runner reports:
INI actual : /usr/local/lib/php.ini
More .INIs :
When this file is a copy of the shipped php.ini-developement
resp. php.ini-production (I tried both), all tests are failing.
Through some expermentation I found that the variables_order
setting (which is "GPCS" in both php.ini files) is causing the
tests to fail. It seems to be necessary that "E" is included
on my system.
Through further expermentation I found that the environment
variable PATH is necessary to successfully run the tests.
Adding the following line at the beginning of run-tests.php
was sufficient:
$_ENV['PATH']=getenv('PATH');
My PATH contains nothing special:
/usr/local/bin:/usr/bin/:/cygdrive/c/WINDOWS/system32/:/cygdrive/c/WINDOWS/:/cyg
drive/c/WINDOWS/System32/Wbem/
Previous Comments:
------------------------------------------------------------------------
[2013-08-23 01:21:38] johan...@php.net
So you most likely have another php.ini which is loaded which tries to load a
shared extension which fails.
the test system is supposed to verify PHP wors with "all" *valid*
configurations.
check the ini files the test runner mentions at the top of the output under
"INI actual" and "More .INIs"
------------------------------------------------------------------------
[2013-08-22 14:43:36] cmbecker69 at gmx dot de
Indeed it is an issue related to the php.ini. When I remove it or
disable it for single tests with -n, most tests succeed (I'll
send a report about the failing tests to the qa-reports list).
According to README.TESTING [Which php.ini is used] it shouldn't
matter which php.ini is used. But both php.ini-production as well
as php.ini-development cause all tests to fail ("error while loading
shared libraries").
However, no errors are reported when running PHP with either of both php.ini
files.
------------------------------------------------------------------------
[2013-08-22 08:22:04] yohg...@php.net
You might have linked with incompatible library.
ldd php or ldd libphp5.so too see what are linked.
It may happen during build also.
I recently helped a user who had build problem due to libtool installed under
/usr/local. Explicitly using proper libtool solved the problem.
Look for suspicious errors in build log, too.
------------------------------------------------------------------------
[2013-08-22 05:50:07] s...@php.net
This looks like some environment problem. PHP does not load its own shared
libs,
so whatever is going wrong is going wrong either in the compiler or in the
environment. If you're getting this message with tests but not when you run
either -v or -i, the difference may be either php.ini or some environment vars.
------------------------------------------------------------------------
[2013-08-21 22:40:37] cmbecker69 at gmx dot de
For most development I'm using "normal" Windows builds,
but for some experiments I prefer the Unix toolchain,
so Cygwin comes in handy (I could use a virtual machine,
but it seems a bit heavyweight).
I should have noted in the first place that the compiled
PHP seems to run fine; at least I haven't noticed any issues
yet (neither CLI nor CGI).
basic/001.out:
/home/cmb/php-5.5.2/sapi/cli/php.exe: error while loading
shared libraries: ?: cannot open shared object file: No
such file or directory
The other .out files have the same message (I've checked
only a handful, however).
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=65497
--
Edit this bug report at https://bugs.php.net/bug.php?id=65497&edit=1
