Anybody get around the php __FILE__ problem on Solaris 8/9?
|
madison
Joined: 2002-09-13
Posts: 20 |
Posted: Tue, 2005-08-30 12:51
|
|
Has anybody gotten gallery 2 to work with solaris 8 or 9? Every version of PHP for solaris that I have tried has the __FILE__ directive bug (see below). I haven't tried php 5 yet since we have a lot of php apps that would have to be tested under 5. If you have gotten it to work, could you tell me which version of PHP. See: Thanks, |
|
Posts: 32509
- did you report your issue on php.net as a bug?
- what about using php 5 as cgi for g2 and keeping php 4 as mod_php for other applications?
Posts: 20
Update: I've installed PHP 5.0.4 with apache 2.0.49 and the install still fails for FILE directive supported.
I'll report the bug to php.net, but it looks like this issue has been around a long time without any progress.
Posts: 8601
I ran G2 on solaris 8, oracle 9 a while back and it worked.. don't recall the exact php version, but it was php4.
Posts: 32509
madison, there must be some dependencies on c libraries or so, because we have heard of this issue also on some freebsd systems and they also tried pretty much every php version.
what could help... rebuild / recompile your whole box with the latest stable versions of everything.
Posts: 2
Yes, I see it, too. I just posted a reply to the above thread.
Yes again, I can reproduce it using the simple example given. That is under PHP 4.4.0 and Apache 2 running on Solaris 9, SPARC.
-Markus
Posts: 32509
we can only point you to the php.net -> bugs section. that's a php issue, g2 can't do anything about it.
Posts: 3
I believe this has to do with path permissions, and I believe that g2 COULD diagnose it if they chose to:
http://bugs.php.net/bug.php?id=34552
Posts: 32509
I'm curious what the PHP dev's answer is to your comment in the bug report.
Whether they will change the documentation for __FILE__ or if there's actually a fix for that.
Anyway, I can't reproduce your results.
Test case:
/tmp/ has 777
/tmp/foo/ has 000
/tmp/foo/bar/ has 755
/tmp/foo/bar/test.php has 755
test.php contents:
print __FILE__;
print "\n";
Expected output of php -f test.php:
/tmp/foo/bar/test.php
Actual output:
/tmp/foo/bar/test.php
=> Cannot reproduce your problem on this RedHat kernel 2.4 box.
Posts: 3
Do an include.
Try it through a web page if that doesn't work.
Posts: 32509
Even including is no problem. No time to test mod_php instead of CLI. But you claim you can reproduce it even with CLI and that filesystem permissions are the problem, which I cannot reproduce. Thus I think your theory probably is either wrong or only applies to your platform.
Posts: 3
CLI behaves incorrectly in various ways, but I can't seem to get it to behave exactly the same way as through the web interface.
sudo su anotheruser -c "php ./test.php"
yields (in the private directory
./test.php<p>./file2.php
Which is clearly incorrect.
Note that my private directory is only 711, not 000.
Note that I posted my test case in .tar.gz to easily set it up.
You say you can't reproduce my results, but you didn't really try. Doesn't RH come with apache and mod_php?
I am looking forward to a response from php.
Posts: 32509
You're claiming that the problem is also reproducible in CLI. And from a filesystem permission point of view, using 000 permissions isn't any different than using sudo with 700 permissions.
Anyway, good luck with finding the bugger and even more so with convinging the PHP guys to fix it.
Reporting PHP bugs isn't the simplest thing there is. You have to follow their exact protocol and even then when it seems crystal clear to you, it's not for sure that it will be fixed.
Best debug PHP with a real debugger, find the problematic code and post your patch to the bug report. The PHP source code has quite a learning curve though.