Re: [PHP-DEV] Re: 5.3 Backwards Compatibility
Alexey Zakhlestin wrote: On Tue, Sep 9, 2008 at 7:07 PM, Lester Caine [EMAIL PROTECTED] wrote: Main problem here - I think - is that in the past I managed to work without PEAR, but increasingly I'm finding some PEAR package needs to be installed to do things which in the past simply worked :( Since the customer sites are secure without internet access, simply downloading things via the installer does not work. This may simply be because libraries that included some of this stuff are now simply switching to PEAR instead. can you provide some example? For example - a bad one since these are pulled in by the project, but it is what I have currently documented. The crib sheet http://www.bitweaver.org/wiki/Version2.1+Windows+niggles was needed to help get new users working, where previous installs simply worked from the zip. http://www.bitweaver.org/downloads/file/11619?highlight=PEAR works with PHP5.2.6 but gives errors on 5.3.0 Those errors now need to be isolated between the core code and the PEAR and other libraries. It takes some time to test every possible path in a full bitweaver install :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Backwards Compatibility
Lukas Kahwe Smith wrote: Hi, So let me get this straight, you are complaining that all the new features and changes in the 5.3.0 alpha releases are not perfectly documented yet? PLEASE re-read the original post. If my comments and QUESTIONS are taken as complaints then OK. That is not what was intended. searching on 'namespace' was not giving me anything - I did not think to try 'namespaces' - goto has not got any notes yet? - I've not even looked at phar as it's not on the list I gave the link for so I assume it's still an optional PECL package ... The 'complaint' that I have is that the changes being introduced DO seem to be bringing in problems which when corrected for 5.3 then cause other problems for previous versions of PHP. As an example, the bitweaver framework currently runs out of the box on PHP4 and PHP5. RUNNING it on PHP5.3 gives various warnings and errors that handling for 5.3 then messes up previous versions although WHEN migration is documented there may be options provided that solve those problems? ( And PEAR comes into this equation since potentially we may have to take care of pre and post 5.3 situations? ) Hanging fixes through the code with 'version selects' has not been necessary much up to now but 5.3 seems to be heading that way? We are currently working through the bitweaver 2.1 testing, on 5.2.6 and below so have not yet had time to do any more than checking the code runs on 5.3. The list of things to be looked at on 5.3 was growing so has had to be shelved until the next bitweaver release is out. One has to allocate time productively and BW is currently paying the mortgage for me! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
On 10.09.2008, at 03:22, Stanislav Malyshev wrote: I disagree. The idea is that I get control over how I manage to global namespace. As such its sensible that I want to use mysql in my code instead of DB::mysql. You may use it. You just won't get wildcard imports, because that doesn't work conceptually. Also when it comes to resolution, inclusion order should not matter, period. if it does we have a serious flaw in our design. if we cannot We already have this serious flaw in our design. If we use new Foo(), and it's definition not included, it resolves differently (namely, to fatal error) than if we had included the definition. Also, with inheritance, if you include or define inherited classes in wrong order - i.e. child before parent - you may get problem too. You'd say this can be changed by autoloading, moving classes around, etc. - but behavior you complain about can be changed easily too, you just insist there would be no possible case, however hard you try to make a mistake, to get different resolution. All the issues you note will give you a nice error message and do not run the risk of silent misbehavior. make a performant solution in this case, we better have nothing. that I don't see how it's better to have nothing at all than a solution that works in 99% of cases - unless you try on purpose to write code that doesn't work. I also find it very strange that you and other people are so insistent on having no namespace solution at all. How that would help you? How that would make PHP better? As stated above, the key is that in 1% of the cases you could end up running totally different code than expected. This means it will be hard to debug and worse opens up an entirely new class of security issues. if some core developers have extensive experience with namespaces in Java and packages in other languages, these people have done more with this construct in PHP than many of us have. Also while I do not know all You seem to suppose neither me nor people I talked with didn't try to do things with namespaces in PHP. This is not correct. I did not say that. I said: they have all used the namespace implementation in PHP 5.3 _more_ extensively than probably all core developers notice the more and the probably .. that they are solid developers. So I think you are brushing their expectations off too lightly here. By brushing too lightly you mean spending three days in discussion, explaining repeatedly point by point each decision and each tiny point of each argument, in full detail, right? You are not discussing most points. For the most part you are saying these people are using (or trying to use) namespaces wrong. The fact that people expect that they can call a function from a namespace in a way that looks different from a static method call however is imho clearly something that needs to be addressed. One way I don't see why they have to insist on that. I think it's just misconception, making artificial differences where they do not exist. Because its important to quickly locate logic, because there is a huge difference in a function and a static method. Actually I find it quite irritating that you can even argue that its irrelevant if something a function or a static method call. This to me means you have left sound reasoning and are just being defensive. I am not convinced that you have demonstrated the mentioned used cases are really so clearly the wrong way that they should not be supported. What could convince you that something is a wrong way, theoretically? I showed that it has hight WTF factor, can lead to potential bugs, and does not add anything to functionality. So far strongest argument for them I got is I don't want :: in names. For me, don't want :: in names versus buggy unmaintainable code is clearly wrong way. But some think otherwise, that's their right. No, people asked to be able to: - shorten class/function calls - be able to differentiate calls to namespaced functions vs. static method calls This has nothing to do with people not liking double colons. I think that PHP is not an OO language and as such there is no reason to Namespaces is an OO feature, however. It is only natural that if you don't want to touch OO, you get no namespaces. PHP has tons of features that make sense only if you use OO, that's one more of them. I disagree. There is nothing OO only about namespaces conceptually. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Backwards Compatibility
On 10.09.2008, at 09:13, Lester Caine wrote: Lukas Kahwe Smith wrote: Hi, So let me get this straight, you are complaining that all the new features and changes in the 5.3.0 alpha releases are not perfectly documented yet? PLEASE re-read the original post. If my comments and QUESTIONS are taken as complaints then OK. That is not what was intended. I am pretty sure I read that you complained that information is scattered or unavailable. If I misunderstood you I am sorry. The 'complaint' that I have is that the changes being introduced DO seem to be bringing in problems which when corrected for 5.3 then cause other problems for previous versions of PHP. As an example, the bitweaver framework currently runs out of the box on PHP4 and PHP5. RUNNING it on PHP5.3 gives various warnings and errors that handling for 5.3 then messes up previous versions although WHEN migration is documented there may be options provided that solve those problems? ( And PEAR comes into this equation since potentially we may have to take care of pre and post 5.3 situations? ) Hanging fixes through the code with 'version selects' has not been necessary much up to now but 5.3 seems to be heading that way? We are currently working through the bitweaver 2.1 testing, on 5.2.6 and below so have not yet had time to do any more than checking the code runs on 5.3. The list of things to be looked at on 5.3 was growing so has had to be shelved until the next bitweaver release is out. One has to allocate time productively and BW is currently paying the mortgage for me! Obviously the goal is to minimize BC issues as much as possible. Actually there has to be really sound reason to break BC. So whenever you discover a BC issue that is not noted on the scratchpad please make us aware of this by opening a bug report or by sending a mail to this list. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Backwards Compatibility
2008/9/10 Lester Caine [EMAIL PROTECTED]: Lukas Kahwe Smith wrote: Hi, So let me get this straight, you are complaining that all the new features and changes in the 5.3.0 alpha releases are not perfectly documented yet? PLEASE re-read the original post. If my comments and QUESTIONS are taken as complaints then OK. That is not what was intended. searching on 'namespace' was not giving me anything - I did not think to try 'namespaces' - goto has not got any notes yet? - I've not even looked at phar as it's not on the list I gave the link for so I assume it's still an optional PECL package ... The 'complaint' that I have is that the changes being introduced DO seem to be bringing in problems which when corrected for 5.3 then cause other problems for previous versions of PHP. As an example, the bitweaver framework currently runs out of the box on PHP4 and PHP5. RUNNING it on PHP5.3 gives various warnings and errors that handling for 5.3 then messes up previous versions although WHEN migration is documented there may be options provided that solve those problems? ( And PEAR comes into this equation since potentially we may have to take care of pre and post 5.3 situations? ) Hanging fixes through the code with 'version selects' has not been necessary much up to now but 5.3 seems to be heading that way? We are currently working through the bitweaver 2.1 testing, on 5.2.6 and below so have not yet had time to do any more than checking the code runs on 5.3. The list of things to be looked at on 5.3 was growing so has had to be shelved until the next bitweaver release is out. One has to allocate time productively and BW is currently paying the mortgage for me! Lester, if you have more complaints or suggestions regarding PEAR, I would like to ask you to go on pear-dev. We'll be happy to help you resolve the situations or work something out. Many developers there are running 5.3 as testers and we have had all the problems. Thank you very much, -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
On Sep 9, 2008, at 6:22 PM, Stanislav Malyshev wrote:
if we cannot
We already have this serious flaw in our design. If we use new Foo
(), and it's definition not included, it resolves differently
(namely, to fatal error) than if we had included the definition.
Also, with inheritance, if you include or define inherited classes
in wrong order - i.e. child before parent - you may get problem too.
You'd say this can be changed by autoloading, moving classes
around, etc. - but behavior you complain about can be changed
easily too, you just insist there would be no possible case,
however hard you try to make a mistake, to get different resolution.
make a performant solution in this case, we better have nothing.
I don't see how it's better to have nothing at all than a solution
that works in 99% of cases - unless you try on purpose to write
code that doesn't work. I also find it very strange that you and
other people are so insistent on having no namespace solution at
all. How that would help you? How that would make PHP better?
Let me advance an idea here, from somebody's who watched this issue
for a bit, if I may.
The idea is as follows: By writing one's *own* namespace-autoloader-
conceptual-framework (*cough*), there have been many, many, ideas
over the years and many, many implementations. Usually, the correct
one seems to be the one written by the developer arguing for their
specific variant. This is somewhat to be expected, as a decent amount
of ego often gets developers through the day.
At one time, this kind of cleverness often took the form of:
include($dynamic_location . $dynamic_filename);
Not too ugly... yet. Seems to make perfect sense. At first.
Lets add a few years, shall we?
foreach ($namespace as $dynamic_location = $dynamic_filename) {
include($dynamic_location . $dynamic_filename);
}
Not too shabby so far... until $namespace becomes an array with, say,
40 or 400 even 4000 entries, and somebody doesn't want to be
hassled with all that upkeep, and just wants the computer to fix
it. So they start getting clever. They start expecting the language
to search through all 4000 locations (be they files or objects, or
*whatever*, it really doesn't matter), looking for the right thing
the developer wants. (I'd write meta-code for this, but my built-in
insanity over-ride precludes me from doing so.)
Where namespaces, indeed, where dynamically loading code based on
arguments has gone south for the last 40 years(!) is not because of
stubbornness, or because all-we-needed-was-another-language, or all-
we-needed-was-better-syntax-characters-in-a-language, but rather,
because it's a really, really, hard problem to fix.
Conceptually, it's a really simple task to 'do what a programmer
wants'. Computationally, it's hard.
Analogy:
A small child leaves toys strewn all over the floor.
A few solutions:
1) Leave the floor as is.
The child will want some easier way of finding things, because
there's stuff all over the floor, and they're grabbing the wrong
thing all the time. They'll try to do their own organization, and
will fail, and succeed, in various ways.
If the child does not get what they want, the child pouts.
2) Place clearly colored buckets for specific kinds of toys about the
floor.
Eventually, the child wants different things in different buckets,
the same thing in multiple buckets, or things to only be in the blue
bucket after taking a toy from the red bucket.
If this does not happen, the child pouts.
3) Hire a full time nanny to constantly re-arrange toys in bins, and
buckets, and on shelves, to duplicate toys for them to be in multiple
locations, to constantly change and modify the toys themselves
depending on what the child has asked for.
When the child does not get what they want, because the nanny is
slow, the child pouts.
Now, solution number 3 has sometimes worked for years, in *certain*
languages, where the nanny can be front-loaded into a compile phase
of some kind, so it's okay if 80 seconds are consumed by toy
management, or the language can dynamically create an toy-stack-of-
all-possible-combinations, according-to-rules, as a cost of severe
RAM and toy-stack persistence, and solution number 2 has a heavy
cost, and solution number 1 is where PHP is at in many ways.
...but the child will still pout.
The problem is not the toys, or how they are arranged, sorted,
managed, or manipulated.
-Bop
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Opinion needed (bug #45928)
Am 10.09.2008 um 10:52 schrieb Tullio Andreatta ML: fstat on a open-ed fd can't stat a symbolic link, since open(symlink) returns a file descriptor of the target file, or -1 if it's a dangling link ... Yes, that's right. So Arnaud's patch at http://arnaud.lb.s3.amazonaws.com/45928.patch looks fine to me. Someone with karma should commit this... One more thought: Maybe the same patch should also be applied to function zend_stream_stdio_fsizer() in the same file? - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array and call_user_function
Thanks for your response, but I'm unable to make it work. I have changed the
code, and it works with strings and even with arrays, but not with hashes:
Am I missing something?
zval *hash;
zval **args[2], *func, *retval;
zval *str;
MAKE_STD_ZVAL(retval);
MAKE_STD_ZVAL(func);
ZVAL_STRING(func, estrdup(handler), 0);
MAKE_STD_ZVAL(str);
ZVAL_STRING(str, estrdup(m-sender), 0);
MAKE_STD_ZVAL(hash);
ALLOC_HASHTABLE(hash);
zend_hash_init(hash, 0, NULL, NULL, 1);
g_hash_table_iter_init (iter, m-params);
while (g_hash_table_iter_next (iter, key, value)) {
zend_hash_add(hash,
g_strdup(key),
strlen(key),
g_strdup(value),
strlen(value),
NULL);
}
args[0] = hash;
args[1] = str;
if (call_user_function_ex(EG(function_table),
NULL,
func,
retval,
2,
args,
0,
NULL TSRMLS_CC) == FAILURE) {
g_debug(error calling method: %s, handler);
}
...
Thanks a lot!
AntP
2008/9/8 Marcus Boerger [EMAIL PROTECTED]
Hello mr,
Monday, September 8, 2008, 6:58:19 PM, you wrote:
Hi all,
I'm having problems passing an array to the function call_user_function
as
parameter. This is the code:
zval *args[3], *func, *retval;
args maust be *** not **
MAKE_STD_ZVAL(func);
MAKE_STD_ZVAL(retval);
MAKE_STD_ZVAL(args[0]);
MAKE_STD_ZVAL(args[1]);
MAKE_STD_ZVAL(args[2]);
ALLOC_HASHTABLE(args[2]);
// creates hash and fills
zend_hash_init(args[2], 0, NULL, NULL, 0);
g_hash_table_iter_init (iter, m-params);
while (g_hash_table_iter_next (iter, key, value)) {
zend_hash_add(args[2], key, strlen(key), value, strlen(value),
NULL);
}
ZVAL_STRING(args[0], estrdup(m-sender), 0);
ZVAL_STRING(args[1], estrdup(m-cmd), 0);
ZVAL_STRING(func, estrdup(handler), 0);
if (call_user_function(EG(function_table),
NULL,
func,
retval, 3,
args TSRMLS_CC) == FAILURE) {
g_debug(error calling method: %s, handler);
}
zval_dtor(retval);
zval_dtor(func);
zval_dtor(args[0]);
zval_dtor(args[1]);
zend_hash_destroy(args[2]);
FREE_HASHTABLE(args[2]);
args[2] is wrong and anyway all three need to be zval_ptr_dtor()
marcus
I suppose that the problem is the conversion between the Hash and the
zval,
but I don't know how to do it.
Thanks in advance :)
regards
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Opinion needed (bug #45928)
On Wednesday 10 September 2008 11:25:40 Christian Schneider wrote: Am 10.09.2008 um 10:52 schrieb Tullio Andreatta ML: fstat on a open-ed fd can't stat a symbolic link, since open(symlink) returns a file descriptor of the target file, or -1 if it's a dangling link ... Yes, that's right. So Arnaud's patch at http://arnaud.lb.s3.amazonaws.com/45928.patch looks fine to me. Someone with karma should commit this... One more thought: Maybe the same patch should also be applied to function zend_stream_stdio_fsizer() in the same file? Committed, applied to zend_stream_stdio_fsizer() too. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array and call_user_function
I have solved the problem. I had confused the functions hash_* with the
funtions array_*. This works:
MAKE_STD_ZVAL(hash);
array_init(hash);
g_hash_table_iter_init (iter, m-params);
while (g_hash_table_iter_next (iter, key, value)) {
add_assoc_string(hash, key, value, 0);
}
Thanks for your help and your patience :)
AntP
2008/9/10 mr esnafrao [EMAIL PROTECTED]
Thanks for your response, but I'm unable to make it work. I have changed
the code, and it works with strings and even with arrays, but not with
hashes: Am I missing something?
zval *hash;
zval **args[2], *func, *retval;
zval *str;
MAKE_STD_ZVAL(retval);
MAKE_STD_ZVAL(func);
ZVAL_STRING(func, estrdup(handler), 0);
MAKE_STD_ZVAL(str);
ZVAL_STRING(str, estrdup(m-sender), 0);
MAKE_STD_ZVAL(hash);
ALLOC_HASHTABLE(hash);
zend_hash_init(hash, 0, NULL, NULL, 1);
g_hash_table_iter_init (iter, m-params);
while (g_hash_table_iter_next (iter, key, value)) {
zend_hash_add(hash,
g_strdup(key),
strlen(key),
g_strdup(value),
strlen(value),
NULL);
}
args[0] = hash;
args[1] = str;
if (call_user_function_ex(EG(function_table),
NULL,
func,
retval,
2,
args,
0,
NULL TSRMLS_CC) == FAILURE) {
g_debug(error calling method: %s, handler);
}
...
Thanks a lot!
AntP
2008/9/8 Marcus Boerger [EMAIL PROTECTED]
Hello mr,
Monday, September 8, 2008, 6:58:19 PM, you wrote:
Hi all,
I'm having problems passing an array to the function call_user_function
as
parameter. This is the code:
zval *args[3], *func, *retval;
args maust be *** not **
MAKE_STD_ZVAL(func);
MAKE_STD_ZVAL(retval);
MAKE_STD_ZVAL(args[0]);
MAKE_STD_ZVAL(args[1]);
MAKE_STD_ZVAL(args[2]);
ALLOC_HASHTABLE(args[2]);
// creates hash and fills
zend_hash_init(args[2], 0, NULL, NULL, 0);
g_hash_table_iter_init (iter, m-params);
while (g_hash_table_iter_next (iter, key, value)) {
zend_hash_add(args[2], key, strlen(key), value, strlen(value),
NULL);
}
ZVAL_STRING(args[0], estrdup(m-sender), 0);
ZVAL_STRING(args[1], estrdup(m-cmd), 0);
ZVAL_STRING(func, estrdup(handler), 0);
if (call_user_function(EG(function_table),
NULL,
func,
retval, 3,
args TSRMLS_CC) == FAILURE) {
g_debug(error calling method: %s, handler);
}
zval_dtor(retval);
zval_dtor(func);
zval_dtor(args[0]);
zval_dtor(args[1]);
zend_hash_destroy(args[2]);
FREE_HASHTABLE(args[2]);
args[2] is wrong and anyway all three need to be zval_ptr_dtor()
marcus
I suppose that the problem is the conversion between the Hash and the
zval,
but I don't know how to do it.
Thanks in advance :)
regards
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
Hi lists, there is a Problem with pdo_sqlite in PHP 5.3. (downloaded half an hour ago from snaps) I've sent a report here : http://pecl.php.net/bugs/bug.php?id=14098 Anyway php_pdo_sqlite_external doesn't have this problem but isn't available in 5.3 windows-builds anymore. Is it possible to activate this extension by default since it is the same source like normal pdo_sqlite? kind regards, Daniel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggestion to increase the max_input_nesting_level
Guilherme Blanco wrote: Hm... Actually at that time I was not able to reproduce the limit, and I wrote a fix that worked well and reduced the number of nest calls. Maybe the guy that notified me was using it. Here is the changeset I did to fix the issue: http://trac.phpdoctrine.org/changeset/4397 But right now I'll have to go back to add some scheduled support, and I was afraid to fall into the same situation again, and I messaged the list. @Derick: If this is a xdebug specific, is there a way to you increase this number? Regards, Why? Running xdebug in production environments is not something people (should) do. And anyone using xdebug is probably smart enough to change a .ini setting to avoid what you are suggesting. Just add an entry to your FAQ / Manual about it. -- Rodrigo Saboya -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
Dear Srs, I'm trying to compile a statically linked, without shared libs, CGI version of PHP, I've already tested with 5.2.6 and 5.2.7-dev. Is there any option in ./configure to compile PHP with this feature? Also I have tried passing CC and CFLAGS environment variables with -static flags.. but the CGI builds using shared libs, example: # file /tmp/php-cgi /tmp/php-cgi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped # ldd php-cgi | head libcrypt.so.1 = /lib/libcrypt.so.1 (0x00335000) libc-client.so.0 = /usr/lib/libc-client.so.0 (0xb7f38000) libexslt.so.0 = /usr/lib/libexslt.so.0 (0x00367000) libz.so.1 = /usr/lib/libz.so.1 (0x00323000) libm.so.6 = /lib/tls/libm.so.6 (0x002fe000) libaspell.so.15 = /usr/lib/libaspell.so.15 (0x00767000) libpspell.so.15 = /usr/lib/libpspell.so.15 (0xb7f36000) librt.so.1 = /lib/tls/librt.so.1 (0x006b2000) libmysqlclient.so.14 = /usr/lib/mysql/libmysqlclient.so.14 (0xb7dff000) libmcrypt.so.4 = /usr/lib/libmcrypt.so.4 (0xb7dce000) How can I compile statically the CGI version of PHP? Thanks!! Regards, -- Santi Saez http://woop.es -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
[EMAIL PROTECTED] escribió: Dear Srs, I'm trying to compile a statically linked, without shared libs, Why you want such thing ? Is there any option in ./configure to compile PHP with this feature? No. How can I compile statically the CGI version of PHP? Thanks!! even if you manage to link all libraries statically, you will end with a huge, memory hungry and hard to debug php binary that anyways require shared libc at runtime ;-P -- A computer is like an Old Testament god, with a lot of rules and no mercy. Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research Development http://www.opensuse.org/ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
On Wed, 10 Sep 2008 11:06:32 -0400, Cristian Rodríguez [EMAIL PROTECTED] wrote: Dear Cristian, I'm trying to compile a statically linked, without shared libs, Why you want such thing ? We want to provide a method to customize PHP version to our clients; for example, all our servers run with PHP 5.1.6, but if one client needs PHP v5.2.6 to run X CMS.. so we provide a statically linked version of the CGI for 5.2.6. In the future, if we upgrade from CentOS 4 to CentOS 5 (for example).. all clients running with the default PHP version in the server will not have problem. But clients with personalized PHP version running as CGI, will have problems: there will be no available the shared libs wich is dynamically linked to.. So, we want to provide this version of the CGI.., we know that the version of the CGI will be bigger, and that's not a good idea, but we need to do it ;-( How can I compile statically the CGI version of PHP? Thanks!! even if you manage to link all libraries statically, you will end with a huge, memory hungry and hard to debug php binary that anyways require shared libc at runtime ;-P Yes, it maybe a problem.. Now we're using statifier [1] to convert dynamically linked executables and all it's libraries in one file: # file php-cgi php-cgi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped # ldd php-cgi | head -10 libcrypt.so.1 = /lib/libcrypt.so.1 (0x00335000) libc-client.so.0 = /usr/lib/libc-client.so.0 (0x00397000) libexslt.so.0 = /usr/lib/libexslt.so.0 (0x00367000) libz.so.1 = /usr/lib/libz.so.1 (0x00323000) libm.so.6 = /lib/tls/libm.so.6 (0x002fe000) libaspell.so.15 = /usr/lib/libaspell.so.15 (0x00767000) libpspell.so.15 = /usr/lib/libpspell.so.15 (0x00111000) librt.so.1 = /lib/tls/librt.so.1 (0x006b2000) libmysqlclient.so.14 = /usr/lib/mysql/libmysqlclient.so.14 (0x001c8000) libmcrypt.so.4 = /usr/lib/libmcrypt.so.4 (0x00f67000) # statifier php-cgi php-cgi.statifier # file php-cgi.statifier php-cgi.statifier: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, not stripped # ldd php-cgi.statifier not a dynamic executable statifier'd version of the CGI works fine.. but we're looking a better method to directly built the CGI. # ls -lh php-cgi php-cgi.statifier -rwxr-xr-x 1 root root 7.0M Sep 10 15:10 php-cgi -rwxr-xr-x 1 root root 19M Sep 10 17:14 php-cgi.statifier Regards, [1] http://statifier.sourceforge.net/ -- Santi Saez http://woop.es -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
This should go on the main bug tracker rather in PECL, there isn't a seperate release on PECL any more for PDO extensions. I can reproduce this on Windows but only with VC6 builds. The VC9 builds are working without issue. I'll look when I'm using a Windows machine. Scott Daniel Henning wrote: Hi lists, there is a Problem with pdo_sqlite in PHP 5.3. (downloaded half an hour ago from snaps) I've sent a report here : http://pecl.php.net/bugs/bug.php?id=14098 Anyway php_pdo_sqlite_external doesn't have this problem but isn't available in 5.3 windows-builds anymore. Is it possible to activate this extension by default since it is the same source like normal pdo_sqlite? kind regards, Daniel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
statifier'd version of the CGI works fine.. but we're looking a better method to directly built the CGI. you can always use llvm and compile all libraries you need to bitcode and then link them with PHP. that way will enable more optimizations and will also reduce the binary size, since llvm will remove the library functions that PHP doesn't use. (details on how to do this are too much off-topic for this list) Still, upgrading a library only represents a problem if its ABI changes (usually the filename changes as well). If not, there isn't any trouble. Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
Cristian Rodríguez kirjoitti: [EMAIL PROTECTED] escribió: Dear Srs, I'm trying to compile a statically linked, without shared libs, Why you want such thing ? Is there any option in ./configure to compile PHP with this feature? No. Wrong: --disable-shared --enable-static Might or might not work, no guarantees. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Backwards Compatibility
Hello Lester, Tuesday, September 9, 2008, 6:05:38 AM, you wrote: While I have loaded 5.3.? changing any of my existing code base to remove warnings is not likely to happen any time soon since compatibility with users who are still running older versions of PHP still needs to be maintained. I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be currently the only reference to changes? But where do I find the detail on how things ARE currently implemented such as namespace and (fingers down throat) goto? Another major concern here since maintaining BC with *PHP4* is still an unfortunate current requirement in the field is what happens when PEAR actually uses namespace and other 5.3 only features. HOW will we manage accessing versions of PEAR that are compatible with our active codebase and so ensure that we have compatible sets of packages? PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4 then we cannot support PEAR either. Anyway, as far as I know PEAR does a good job in maintenance, especially in supporting both PHP 4 and 5. And some people are working on a new system that supports PHP 5. marcus Personally I can't stand the CURRENT problems that is caused by not knowing which version of a PEAR extension users actually have and in order to ensure a COMPATIBLE version, but in future will the PEAR installer pick up a correct version for the copy of PHP actually being run? I get the distinct impression that those pushing for PHP5.3 are simply not making a good case for many of us to even want to follow them down that path? It almost feels like this is a DIFFERENT path to the main stream of PHP6 which many of us are much more desperate to be testing in the field, which seems to have become an ignored backwater? Key elements which have been flagged to PHP6 ( such as BIGINT ) are on hold while new concepts which were not part of the PHP6 reoadmap have been forced through? Since current hardware *IS* 64 bit, actually handling 64 bit numbers properly would be nice :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Backwards Compatibility
Marcus Boerger wrote: Hello Lester, Another major concern here since maintaining BC with *PHP4* is still an unfortunate current requirement in the field is what happens when PEAR actually uses namespace and other 5.3 only features. HOW will we manage accessing versions of PEAR that are compatible with our active codebase and so ensure that we have compatible sets of packages? PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4 then we cannot support PEAR either. Anyway, as far as I know PEAR does a good job in maintenance, especially in supporting both PHP 4 and 5. And some people are working on a new system that supports PHP 5. Marcus - I've never USED PHP4 in production, but it will be some time before it has been replaced on a lot of ISP's so at present OUR users require maintaining support for PHP on the only versions they have available - at present. NOW it at least practical to freeze a version that supports PHP4 and all the 'extras' that are compatible with that version and not allow any new features to be included in that build. SO we do not have to test changes to the code base for PHP5.3 against PHP4. There have always been problems with using 'new' features but making them available to older versions, which the compatibility libraries provide, but it is looking as if 'Built for PHP5.3' will mean 'will not work on PHP5.2' much more so than previous 'minor version changes'? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
On Wed, Sep 10, 2008 at 17:31, Scott MacVicar [EMAIL PROTECTED] wrote: This should go on the main bug tracker rather in PECL, there isn't a seperate release on PECL any more for PDO extensions. Shouldn't the pecl packages be removed then? (so people a) don't download decade old packages and b) stop filing bug reports there) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
On 10 Sep 2008, at 20:26, Hannes Magnusson [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 17:31, Scott MacVicar [EMAIL PROTECTED] wrote: This should go on the main bug tracker rather in PECL, there isn't a seperate release on PECL any more for PDO extensions. Shouldn't the pecl packages be removed then? (so people a) don't download decade old packages and b) stop filing bug reports there) Yep but I don't have any karma to do that. There are probably a few that could get removed. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
hi, On Wed, Sep 10, 2008 at 9:26 PM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 17:31, Scott MacVicar [EMAIL PROTECTED] wrote: This should go on the main bug tracker rather in PECL, there isn't a seperate release on PECL any more for PDO extensions. Shouldn't the pecl packages be removed then? (so people a) don't download decade old packages and b) stop filing bug reports there) Not removed but marked as being released only with php releases or smtg similar :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
On Wed, Sep 10, 2008 at 22:16, Pierre Joye [EMAIL PROTECTED] wrote: hi, On Wed, Sep 10, 2008 at 9:26 PM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 17:31, Scott MacVicar [EMAIL PROTECTED] wrote: This should go on the main bug tracker rather in PECL, there isn't a seperate release on PECL any more for PDO extensions. Shouldn't the pecl packages be removed then? (so people a) don't download decade old packages and b) stop filing bug reports there) Not removed but marked as being released only with php releases or smtg similar :) poteito potato :) Who has the p0w3r and sk1llz to make that happen? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
Pierre Joye wrote: hi, On Wed, Sep 10, 2008 at 9:26 PM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 17:31, Scott MacVicar [EMAIL PROTECTED] wrote: This should go on the main bug tracker rather in PECL, there isn't a seperate release on PECL any more for PDO extensions. Shouldn't the pecl packages be removed then? (so people a) don't download decade old packages and b) stop filing bug reports there) Not removed but marked as being released only with php releases or smtg similar :) Cheers, There are actually quite a few that need this Now in PHP Core status set on them, with a brief note that they are only useful for very old versions of PHP. Thanks, Elizabeth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
On Wed, Sep 10, 2008 at 10:19 PM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 22:16, Pierre Joye [EMAIL PROTECTED] wrote: hi, On Wed, Sep 10, 2008 at 9:26 PM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 17:31, Scott MacVicar [EMAIL PROTECTED] wrote: This should go on the main bug tracker rather in PECL, there isn't a seperate release on PECL any more for PDO extensions. Shouldn't the pecl packages be removed then? (so people a) don't download decade old packages and b) stop filing bug reports there) Not removed but marked as being released only with php releases or smtg similar :) poteito potato :) Who has the p0w3r and sk1llz to make that happen? Me and some other, I added the flags a couple of weeks ago. I only have to add the is in core status. I will do it tomorrow. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
Jani Taskinen escribió: Wrong: --disable-shared --enable-static Might or might not work, no guarantees. Dear Jani, Thanks for your reply, I have tried with a very simple: # ./configure --disable-all --disable-shared --enable-static But, generated binary uses shared libs ;-( # file sapi/cgi/php-cgi sapi/cgi/php-cgi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped # ldd sapi/cgi/php-cgi libcrypt.so.1 = /lib/libcrypt.so.1 (0x00335000) libresolv.so.2 = /lib/libresolv.so.2 (0x00375000) libm.so.6 = /lib/tls/libm.so.6 (0x002fe000) libdl.so.2 = /lib/libdl.so.2 (0x002f8000) libnsl.so.1 = /lib/libnsl.so.1 (0x0039e000) libc.so.6 = /lib/tls/libc.so.6 (0x001ca000) /lib/ld-linux.so.2 (0x001b) Thanks anyway! I will try other method.. -- Santi Saez http://woop.es -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
Hi Santi, On Wed, Sep 10, 2008 at 10:39 PM, Santi Saez [EMAIL PROTECTED] wrote: Jani Taskinen escribió: Wrong: --disable-shared --enable-static As you say, this doesn't work. I needed something like this to for profiling. I believe I got the static archive linked, but it was a while ago, so I'm not positive (sadly, the profiling never worked this way). Here is the script I used. I don't think the script itself works, but if you have a look through the last 5 or 6 lines of it, it should be easy enough. http://code.google.com/p/phc/source/browse/trunk/misc/old/get_libphp5_archive Those long lines were created by looking at the make output used for building the shared archive. I think I had to manually remove .o files every time the linker complained, which was a lot, a problem that you don't have with shared libs. Let me know how you get on, Paul On Wed, Sep 10, 2008 at 10:39 PM, Santi Saez [EMAIL PROTECTED] wrote: Jani Taskinen escribió: -- Paul Biggar [EMAIL PROTECTED]
Re: [PHP-DEV] PHP mixin RFC
Jonathan Bond-Caron wrote: http://wiki.php.net/rfc/mixin It seems to me that class_mixin() is a bad idea for the core; it's more of a runkit type functionality than traits. After all, we don't allow dynamic inheritance, or dynamic interfaces... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
