Hi Greg
2009/3/1 Greg Beaver <g...@chiaraquartet.net>:
> hi Kalle,
>
> Thank you very much for your work on this, it is much appreciated.
> Sorry for the delay in replying, I have been out of town for a while.
No problem :)
>
> Kalle Sommer Nielsen wrote:
>> Hi Greg
>>
>> 2009/2/21 Greg Beaver <g...@chiaraquartet.net>:
>>> Hi,
>>>
>>> [snip]
>>
>> Good work!
>>
>>> I do need some help verifying phar as working with the following
>>> configurations:
>>>
>>> any endian any unix with intel CC
>>> any Windows Vista
>>> 64-bit Windows XP
>>> any other supported OS/compiler/processor combo I didn't list.
>>
>> I tested phar under 5.3-cvs and HEAD with Windows Vista 32bit little
>> endian and VC9.
>>
>> Theres only one compilation warning which only exists in HEAD:
>> ext\phar\func_interceptors.c(101) : warning C4101: 'newlen' :
>> unreferenced local variable
>>
>> However tests wise then the following tests fails in 5.3-cvs:
>> Phar front controller with mounted external file
>> [C:\php\src\ext\phar\tests\front.phar.phpt]
>
> It appears that this test is not line-ending agnostic, and I'm about to
> commit a fix, as the problem is simply the length of the string is 172
> instead of 167 due to extra \r. This is very good news :)
>
>> Phar::getSupportedSignatures()
>> [C:\php\src\ext\phar\tests\phar_get_supported_signatures_002.phpt]
>
> This one is perplexing - I wonder if you have built ext/hash statically
> or as a .dll? The phar ext is not detected ext/hash, but the test is
> not skipping because ext/hash is present in the SKIPIF
ext/hash was built staticlly (default)
I looked into the issue and it seems like PHAR_HASH_OK isn't getting
defined, so I assume its a missing AC_DEFINE call in config.w32, so
something along the lines of the following should do if ext/hash is
built staticlly:
if(PHP_HASH != "no" && !PHP_HASH_SHARED) {
AC_DEFINE("PHAR_HASH_OK", 1);
}
using the above code in config.w32 and then buildconf, configure,
nmake and run-tests on that test makes it pass but the test will still
fail if ext/hash is built as shared ofcourse.
>
>> Phar::setStub() (zip-based) [C:\php\src\ext\phar\tests\zip\phar_stub.phpt]
>
> This one is actually troubling, as it looks like a crash is terminating
> the test at the second setStub()
I did some more tests and a couple of fresh checkouts and builds and
this test does not fail anymore for me, if anyone can confirm it would
be good.
>
> I will try to investigate, but if others can confirm this failure on
> their windows, that would be helpful.
>
> Thanks,
> Greg
>
--
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
