Benjamin Tomhave schrieb:
> I tried the 4.0.6 rpm install, but as is common with RPMs, it requires
> specific libraries to be installed -- libraries that are now 2-3 versions
> old (as in, RH7.2 vintage). Doesn't work with a RH8 install.
if you wish everything is possible ... maybe as I who had to build an
StackGuard version in lack of a recent gcc ... so I did it with an old
2.7 instead of 2.9 and it worked for me.
If you read EXTENSIONS from your PHP-4.3.0 directory you might find:
EXTENSION: apache2
PRIMARY MAINTAINER: Aaron Bannert <[EMAIL PROTECTED]>
MAINTENANCE: Maintained
STATUS: Experimental
^^^^^^^^^^^^
Cause its experimental you might ask the maintainer itself for solution ?
... don't get me wrong, I hope you will get it working !!!
I will catch my RH8 in about 2 hours, then I might kick it on my box and
try to get both working, Apache 2 and PHP 4.3.0 ... and as far as I know
me, I would get it going even if I have to hack 48 hour a day, just to
show the possibility ;-)
When finished I will notice you ...
> I did not "hack" any configure scripts. There was a post on php.net under
> Linux installation manual that suggested modifying /usr/sbin/apxs because
> there was an error. It turns out, the error was not using the --with-apxs2
> flag on the configure line.
sorry ... didn't know what you did ... I only read you changed your configure.
> My solution, and the solution which anyone else on old code can try: You can
> regain the old global vars behavior from pre-4.2 days by simply editing your
> php.ini file and changing "register_globals = Off" to "register_globals =
> On".
>
> I went with a RH RPM install for 4.2.x on a different system and made this
> change to php.ini and now am in good shape.
>
> I have not been able to get PHP to compile on RH, but my memory from a year
> ago was that compiling PHP proved to be a major pain in the arse. Why?
> Because the stupid ./configure script is broken!! Pardon my saying so, but
> wtf?!? When you run configure and say things like --with-jpeg and you do an
> "ldconfig -p | grep jpeg" and you see the library exists and is registered,
> then why in the world can't the configure script see the library?!? When I
> compiled 4.1.x a year ago, I had to specify directory paths for every single
> library I wanted to use, whether it be mysql, jpeg, freetype, gd, mm, etc.
> This is absolutely ridiculous! I hope this gets fixed in the near future.
thats why unix is not windowz, cause you have still doing something by yourself
even if you personal could do a "ldconfig -p | grep jpeg" that won't help
as much if you find more than one or nothing. Its a common rule that you
couldn't never ever get all possibilitys to work. And why then hacking the
configure script to help one of a billion to be more easy if other tasks
are more important (like aka security fixes).
The configure of PHP is quit good, if not as good as you wish you might
help the CVS team to rewrite it as you desired ...
Even other configure scripts aren't quit easyer at all !
... but I wonderd also sometime about the "never finding lib" story of
configure, so if you get the time to rewrite it, I will be lucky too ...
;-)
> Mitch -- check out the results of ./configure and make sure it's finding
> your libraries. If it's not, then try specifying the path to the libs
> explicitly (usually =/usr is adequate for me). That may solve your compile
> problem. As for your PEAR issue, that sounds weird. Good luck on that!
good luck to all hacking in the weird, from me too ;-)
--
@ Goetz Lohmann, Germany | Web-Developer & Sys-Admin
\/ ------------------------------------------------------
() He's the fellow that people wonder what he does and
|| why the company needs him, until he goes on vacation.
--
PHP Install Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
