Same here. (same kernel, uClibc version, php version) 
 
I did configure with: "CFLAGS=-march=i486 ... --disable-all" against the 
same ver. of uClibc and also re-conf'd and recompiled the Zend engine but 
to no avail.  
Add. tests have been done with changed php.ini's (exact path was 
included/not included). 
It's *not* a problem of finding the file! 
require('') gives the same error :-( 
sapi/cli/php also yieds the same output 
 
If someone with better knowledge about debugging flex-engines is reading 
this, I would like to mail her my phpinfo() and help with testing... 
 
Thank you. Salut, Joerg

a few other tests: 
it's not the permissions. I tried a complete accessible file in a wide open 
dir... 
including or requiring from an absolute path gives the same error 
there's no difference if the file is empty or text/plain or text/html 
 
Joerg

Hi again! 
 
I finaly nailed it down to be a problem in handling the input buffer 
reading in Zend/zend_language_scanner.c! 
 
With the patch below the resulting phps will work with "include()" and 
"require()" but I know that this so patched file gets generated by lex 
(flex) and so one should perhaps change either the .l input or the 
Zend/flex.skl file(s). 
 
But I did know that there is a big chance that a call to fread() might 
return 0 as a result and that this is absolutely legal and no reason to 
bail out. And in my understanding from flex.skl this is what YY_INPUT() was 
defined to tolerate (aka only bail out if fread() returns < 0)! 
 
But since I'm no flex god, I will leave this to whom it may concern ;-) 
 
Salut, Joerg 
 
BTW: 
jsl@floyd:~/projekte/ep2/src/php-4.3.1> flex -V 
flex version 2.5.4 
 
Of course the follwing hunk will fail on any other machine since every 
other implementation/version of lex (flex) would have generated other line 
numbers... :-) 
 
--- snip ------------------------------------------------------------ 
*** Zend/zend_language_scanner.c	Wed May  7 12:04:39 2003 
--- Zend/zend_language_scanner.c.orig	Wed May  7 12:04:35 2003 
*************** 
*** 3521,3527 **** 
  			YY_FATAL_ERROR( "input in flex scanner 
failed" ); \ 
  		result = n; \ 
  		} \ 
! 	else if ( ((result = fread( buf, 1, max_size, yyin )) < 0) \ 
  		  && ferror( yyin ) ) \ 
  		YY_FATAL_ERROR( "input in flex scanner failed" ); 
  #endif 
--- 3521,3527 ---- 
  			YY_FATAL_ERROR( "input in flex scanner 
failed" ); \ 
  		result = n; \ 
  		} \ 
! 	else if ( ((result = fread( buf, 1, max_size, yyin )) == 0) \ 
  		  && ferror( yyin ) ) \ 
  		YY_FATAL_ERROR( "input in flex scanner failed" ); 
  #endif 
--- snap ------------------------------------------------------------

Not PHP bug, uclibc obviously doesn't work like glibc here.

Technically, this is a php bug.  php calls fflush() on a stream opened readonly.  According to ANSI/ISO C99 and SUSv3, the behavior of fflush() in this case is undefined.  Current glibc behavior is to do nothing and return success.  In the pre-libio-based stdio implementation, glibc set errno and returned failure.  The fflush() in uClibc 0.9.19 set errno, the stream's error indicator, and returned failure.  
When ferror() returned true, php was interpreting it as an fread() failure.

I have changed the default behavior of uClibc's fflush() in this case to match glibc's current behavior.  But this (and several other nonportable code checks) will eventually be configureable.  Hence, this issue could very well pop up again unless the code in php is fixed.