ID: 15983
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: Debian/Linux mips platform
PHP Version: 4.1.2 and 4.2.0
Assigned To: sascha
New Comment:
PHP 4.2.3 works for me also on Debian Woody Sparc, even
though I am using the CGI version and I'm not able to use
PHP as a module, as Apache refuses to start... it seems
that there is some sort of binary incompatibility.
I have the same problem with version 4.1.2, too.
However, this seems to be a different issue, I suppose
that it is better do deal with it elsewhere, right?
Previous Comments:
------------------------------------------------------------------------
[2002-10-01 14:29:32] [EMAIL PROTECTED]
I'm closing this bug for now, use of pread/pwrite has been suspended.
------------------------------------------------------------------------
[2002-09-28 15:19:24] [EMAIL PROTECTED]
PHP 4.2.3 works for me on Debian Woody PowerPC.
------------------------------------------------------------------------
[2002-09-26 11:18:28] [EMAIL PROTECTED]
I cannot ensure you that 4.2.3 solves the problem
as I still have not upgraded from version 4.2.2,
but I am sure that it works, as the only change needed
to make things work for me has been the removal
of the lines that have been kindly removed
for version 4.2.3 (many thanks).
BTW, the same workaround has been backported on the
Debian Woody's 4.1.2 packages, and in a short time
I could check if the fix works on Woody for Sparc.
I also point out that, as this problem seems due to a glibc
bug and not to errors in the PHP code, I have submitted
a bug report to the Debian's glibc maintainer, asking him
to backport a fix for the glibc packages; hence, hopefully,
in the future, updated Linux distributions should have
a fixed glibc package and you could finally ignore this
problem and restore the code using pread().
But I would like to submit you a simple (and perhaps
stupid) suggestion.
Maybe you could provide a ./configure option to explicitly
disable the use of pread() and pwrite(), i.e.
./configure --no-pread --no-pwrite
In this case, you could release without problems the code
using pread() and pwrite(); the person that compiles and/or
packages PHP has the possibility of disabling pread()
and/or pwrite() if things do not work... is this
a bad idea?
------------------------------------------------------------------------
[2002-09-25 16:36:09] [EMAIL PROTECTED]
Sascha it's not a problem of using a feature on their system, it's a
problem that the functionality is broken on their end. Your test,
while possibly being correct, doesn't have a way to check this.... and
I don't really think there is a way.
As of this moment I'm not even sure if there is a released version with
it working.
Marking this as open, as there is nothing the end user can comment back
on to this.
------------------------------------------------------------------------
[2002-09-25 06:17:49] [EMAIL PROTECTED]
If you want us to avoid using certain features of your platform, then
you need to provide specific testcases. We will use these testcases to
determine whether pread/pwrite work on a platform.
Currently, we use this for pread (after echo test > conftest_in):
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
main() { char buf[3]; return !(pread(open("conftest_in", O_RDONLY),
buf, 2, 0) == 2);
And this for pwrite:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
main() { return !(pwrite(open("conftest_in", O_WRONLY|O_CREAT, 0600),
"hi", 2, 0) == 2);
------------------------------------------------------------------------
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
http://bugs.php.net/15983
--
Edit this bug report at http://bugs.php.net/?id=15983&edit=1
