filed bug : https://bugs.php.net/bug.php?id=73777
So now I find this page .. only one page for the memory management of
all of PHP? here :
http://php.net/manual/en/internals2.memory.management.php
So I will try a debug build with -DUSE_ZEND_ALLOC=0 and see what
happens. Won't be very
Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.
GCC is not a requirement. At the very least, PHP compiles on clang and
MSVC, and I believe it works with some other
On 12/14/2016 03:48 PM, Nikita Popov wrote:
On Wed, Dec 14, 2016 at 9:39 PM, Dennis Clarke <dcla...@blastwave.org>
wrote:
On 12/14/2016 03:31 PM, Marco Pivetta wrote:
See https://secure.php.net/supported-versions.php
I see.
I guess the question has to be "why is the 5.6.x co
On 12/14/2016 03:31 PM, Marco Pivetta wrote:
See https://secure.php.net/supported-versions.php
I see.
I guess the question has to be "why is the 5.6.x codebase only to
receive security fixes for a very brief while into 2017" ? Just
curious what the thinking is here.
Dennis
--
PHP
On 12/14/2016 01:29 PM, David Zuelke wrote:
On 14.12.2016, at 16:15, Dennis Clarke <dcla...@blastwave.org> wrote:
On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote:
Hi
On Dec 14, 2016 12:23, "Christoph M. Becker" <cmbecke...@gmx.de> wrote:
Hi!
The end of acti
PHP 5.6 isn't EOL for a further two years, you should be fine.
Thank you so much. I can only guess this is posted on a "lifetime" page
somewhere on php.net but I didn't see it.
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
e gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.
Dennis Clarke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11/24/2016 07:07 PM, Ferenc Kovacs wrote:
Hello everyone,
PHP 5.6.29 RC1 was just released and can be downloaded from:
The diffs from 5.6.28 are found in :
./NEWS
./Zend/tests/debug_info-error-resource.phpt
./configure
./configure.in
./ext/date/lib/timezonedb.h
On 11/24/2016 07:07 PM, Ferenc Kovacs wrote:
Hello everyone,
PHP 5.6.29 RC1 was just released and can be downloaded from:
http://downloads.php.net/~tyrael/
Compiles fine on a Solaris 10 system with the Oracle Studio 12.5 tools.
Not C99 of course but still, a very POSIX tight system.
Running
nforming compiler ( yet ) and the optimization within
the sparc servers is still best done with Oracle Studio tools.
Dennis Clarke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
You can just enable -std=c99 with gcc
I won't be using gcc for this test.
to see it doesn't compile. Some amount of work might be needed for
> true C99 compat.
Oh, I agree. That is fine at this stage. I was merely doing the acid
test to see what happened.
I'd suggest you to reply to
On 11/24/2016 09:09 AM, Dennis Clarke wrote:
On 11/24/2016 06:29 AM, Anatol Belski wrote:
Hi,
PHP 7.0.14 RC1 was just released and can be downloaded from:
Please test it carefully, and report any bugs in the bug system.
First pass instantly fails in the configure stage when using a c99
.
Dennis Clarke
ps: the compiler I will be using :
n0 $ which c99
/opt/developerstudio12.5/bin/c99
n0 $ c99 -V
c99: Studio 12.5 Sun C 5.14 SunOS_sparc 2016/05/31
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
and start migration from all of my
5.6.x work BUT only if I can get it to compile in a very strict POSIX
production environment. I have not seen that ( yet ) but hope it isn't
too far away.
Dennis Clarke
+---+
| open standards
, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.
For a language tool as critical as PHP it would be better to consider
a larger sample size such as 75%+1. However the merit is the issue and
not the mass vote. IMHO.
Dennis Clarke
--
PHP Internals - PHP Runtime
This is a tad tricky but here is what happened.
With a build of 5.6.27 I had no problems until the time came to run
"make test" wherein everything seems normal until this :
FAIL Basic bitwise stream crypto context flag assignment
[ext/openssl/tests/stream_crypto_flags_001.phpt]
FAIL
IMHO, if we decide to move to C99, we should do it the strict way
I forgot to add that GNU GCC allows a lot of non-standard extensions to
slip right through. Unless some CFLAGS are set to warn or error on them.
https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/C-Extensions.html#C-Extensions
long with -D_POSIX_PTHREAD_SEMANTICS and -D_XOPEN_SOURCE=600 where with
a very crisp c99 compiler. Most of these tools exist no where but on a
classic UNIX commercial grade implementation. Sadly.
Dennis Clarke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
through and be sure to report what I see. I
have had no major issues at all with php 5.5.x and 5.6.x releases but
never see 7.x get past basic configure and build steps. I will look into
why.
Dennis Clarke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
s the
use of extensions which may be purely gnuisms or gccisms. These all
become very evident once a strict compiler set of options are used. I
will get it a run through and see what I see.
Dennis Clarke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
not
compile out of the box, yet. However I am looking into why.
Dennis Clarke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Not sure where the definition of "offsetof()" is located but something
seems clearly not C compliant here.
So this is using the Oracle Studio 12.5 compiler tools on a big old
SPARC box running Solaris 10. Any input would be appreciated. The cflags
were permissive and allowed for transition
I tried the php-install mail list but saw no reply thus I will try here.
While attempting a build of 7.0.11 I was presented with :
"/usr/local/build/php-7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c",
line 2195: error: syntax error before or at: struct
The details are over at :
https://issues.apache.org/bugzilla/show_bug.cgi?id=54886
Looks to be a crash caused by php bits.
Anyone have any insights ?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Still seeing this :
.
.
.
checking for bison version... (cached) invalid
configure: WARNING: bison versions supported for regeneration of the Zend/PHP
parsers: 1.28 1.35 1.75 1.875 2.0 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1
2.6 2.6.1 2.6.2 (found: none).
.
.
.
However :
node002 $ which
Hi,
On Mon, 2013-02-25 at 01:58 -0500, Dennis Clarke wrote:
/usr/local/include/curl/curlrules.h, line 143: zero or negative
subscript
/usr/local/include/curl/curlrules.h, line 153: zero or negative
subscript
conftest.c, line 249: warning: implicit function declaration
- Original Message -
From: Johannes Schlüter johan...@schlueters.de
Date: Monday, February 25, 2013 9:17 am
Subject: Re: [PHP-DEV] PHP 5.4.12 and libcurl 7.29.0 configure problem
To: Dennis Clarke dcla...@blastwave.org
Cc: internals@lists.php.net, christopher.jo...@oracle.com
On Mon
So the -m64 is lost. Looking at extg/curl/config.m4, again I see
save_CFLAGS=$CFLAGS
CFLAGS=`$CURL_CONFIG --cflags`
So running `curl-config --cflags` apparently doesn't contain the -m64
flag on your setup. In my opinion curl-config should return this, so
there is a curl issue.
On Mon, 2013-02-25 at 10:49 -0500, Dennis Clarke wrote:
/* The size of `long', as computed by sizeof. */
#define CURL_SIZEOF_LONG 8
This is correct with -m64. Now in your config log there is this compiler
call (quoting your first mail from this thread)
| configure:28678: checking
hi,
On Mon, Feb 25, 2013 at 7:58 AM, Dennis Clarke dcla...@blastwave.org
wrote:
configure in php 5.4.12 seems to have some difficulty with libcurl
7.29.0 :
$ ./configure --with-apxs2=/usr/local/bin/apxs
--with-mysql=/opt/mysql/mysql \
Also we had no issue to build against
configure in php 5.4.12 seems to have some difficulty with libcurl 7.29.0 :
$ ./configure --with-apxs2=/usr/local/bin/apxs --with-mysql=/opt/mysql/mysql \
--with-libxml-dir=/usr/local --sysconfdir=/usr/local/etc \
--includedir=/usr/local/include --libdir=/usr/local/lib \
configure in php 5.4.12 seems to have some difficulty with libcurl 7.29.0 :
$ ./configure --with-apxs2=/usr/local/bin/apxs --with-mysql=/opt/mysql/mysql \
--with-libxml-dir=/usr/local --sysconfdir=/usr/local/etc \
--includedir=/usr/local/include --libdir=/usr/local/lib \
- Original Message -
From: Pierre Joye pierre@gmail.com
Date: Sunday, February 10, 2013 1:55 pm
Subject: Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc':
error: 'struct gdIOCtx' has no member named 'data'
To: Dennis Clarke dcla...@blastwave.org
Cc: Stanislav
There is a problem when an external library is used. Using the bundled
lib fixes this problem (--with-gd)
That worked beautifully :
gd
GD Support enabled
GD Version bundled (2.0.34 compatible)
FreeType Supportenabled
FreeType Linkagewith freetype
FreeType Version
disclaimer : I realize that by working on Solaris I am in fringe OS territory.
So here I am once again trying to build PHP 5.4.11 on a Solaris 10 server
with the following configure options :
./configure --with-apxs2=/usr/local/bin/apxs --with-mysql=/opt/mysql/mysql \
On 01/24/2013 10:47 AM, Dennis Clarke wrote:
So here I am once again trying to build PHP 5.4.11 on a Solaris 10 server
with the following configure options :
So I think that I should be okay. Do I need to upgrade to curl
7.28.2 and then try building PHP 5.4.11 or am I sort of stuck
On 01/15/2013 09:07 PM, Dennis Clarke wrote:
Number of tests : 12276 8329
Tests skipped : 3947 ( 32.2%)
Tests warned:0 ( 0.0%) ( 0.0%)
Tests failed:2 ( 0.0%) ( 0.0%)
Expected fail : 36 ( 0.3%) ( 0.4%)
Tests passed: 8291 ( 67.5
On 01/15/2013 12:09 PM, Dennis Clarke wrote:
Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate the
parsers with it, review the test suite results, and create a github
pull request.
Anything outside of release
currently we have a whitelist for supported bison versions:
http://lxr.php.net/xref/PHP_5_4/Zend/acinclude.m4#6
anything else will be reported, but this doesn't mean that php wouldn't
compile with that, it can also mean that nobody tested and made sure that
it works.
this is why Derick
Unless you are hacking PHP you can ignore Bison. Check the Makefile
Well, the configure output claims that something is wrong, therefore the build
can not be trusted.
I'm just following the defacto way to build PHP and if the configure output
claims
something is wrong .. then it is
Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate the
parsers with it, review the test suite results, and create a github
pull request.
Anything outside of release tarball won't be supported here. Sorry.
However ...
/** For the sake of getting this issue looked into I am going to cross
post
* to two maillists. Maybe the PHP folks see the issue and will reply with an
* update. Who knows.
*/
Original message to the bison mailist :
Le 15 janv. 2013 à 00:19, Dennis Clarke dcla...@blastwave.org
On 01/15/2013 05:03 PM, Dennis Clarke wrote:
Really I would like to hear from the PHP folks on this as it seems
as if PHP is
quite fragile or perhaps simply mysterious.
I don't think any of us test on Solaris regularly, so you can expect the
odd test to fail, but in general
Those old Solaris servers are still out there churning away.
Sure, but there are very few of you and we have limited resources.
granted ... I get it. I do. I ran Blastwave for a decade on shoestring and
prayer and kicked out several thousand SVR4 packages. I really do get it.
We
focus
We
focus those resources on the platforms used by 95% of our users. Feel
free to dig in and send us some patches. Needless to say, all of those
tests pass on Linux, FreeBSD and likely OSX as well.
I will try that theory out on RHEL 6.3 and let you know.
PHP is hardly what I
Please mind that PHP is developed mostly on a volunteer basis and the
work is focused on primarily used platforms. If you want to provide
productive help we'd love having people going through those and provide
fixes for overly specific tests and identifying broken PHP features.
I have a slew
Hi!
As for the odd test failing, I see this :
That looks like a lot of failures in most basic scripts. I suspect
there's some unifying problem to that - what are the .diff files for
some of these failures, is there anything interesting in the PHP error
log?
I will try to wade
therefore I wonder what these PHP folks are on about? Is this a
Warning
or a real configure fault? If the latter then I need to backout bison in order
to build
PHP and then re-install a perfectly functional bison ?
Dennis Clarke
--
PHP Internals - PHP Runtime Development Mailing List
48 matches
Mail list logo
