Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HOWTO Install PHP5
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Wed Aug 10, 2005 4:18 pm    Post subject: Reply with quote

Hi Styles.

That should not happen, I install it with db4 support fine. "db" support is activated by the "berkdb" USE flag.
Are you really sure that you installed a sys-libs/db package of the 4 series, since we support only db-4*?
Please try to reemerge the exact version of db first and then reemerge PHP5 (the one from the overlay).
Code:

emerge =sys-libs/db-4.2.52_p2

_________________
Best regards, Luca.
Back to top
View user's profile Send private message
Styles
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jun 2002
Posts: 82

PostPosted: Wed Aug 10, 2005 5:33 pm    Post subject: Reply with quote

same thing ???

checking for db4 major version... configure: error: Header contains different version
Back to top
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Wed Aug 10, 2005 6:30 pm    Post subject: Reply with quote

Hi, ok, I can't reproduce the bug, so please give me more information, the following would be really helpful:
Code:

emerge -pv dev-lang/php

This will output the version and all the USE flags you're using to install PHP5.
Code:

emerge -Cpv sys-libs/db | grep selected

This will output all the installed versions of sys-libs/db on your system. (Be careful with this command, execute it exactly as it's here, copy&paste it, if you forget the "pv" after the "-C" it would remove the sys-libs/db package instead of simulating what would be done)
Code:

ls -lah /usr/include/db.h

This will output data on the mentioned file.
Just copy&paste the commands, execute them and copy&paste all the output back here. Thanks!
_________________
Best regards, Luca.
Back to top
View user's profile Send private message
Styles
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jun 2002
Posts: 82

PostPosted: Wed Aug 10, 2005 7:16 pm    Post subject: Reply with quote

ya the only db is 4.2 strange??? anyway I'm doing a
Code:
emerge --update --deep --newuse world
(just started so it's going to take a bit) with some new use flags, then I will try again.

I would rebuild the whole box but Opensims was a royal pain in the butt to get up and running.
Back to top
View user's profile Send private message
tessmonsta
Tux's lil' helper
Tux's lil' helper


Joined: 28 Jul 2005
Posts: 114

PostPosted: Thu Aug 11, 2005 2:36 am    Post subject: Reply with quote

Thanks for the tutorial! It really helped with my php5 install.

But now I have a bit of a problem:
Code:
Fatal error: Call to undefined function session_start() in /home/deninet/public_html/index.php on line 6

Appearently, the session extension has been disabled. After a few searches, it seems that I should add "session" to package.use

I'm just guessing, of course. :?
Back to top
View user's profile Send private message
nautiazn85
n00b
n00b


Joined: 05 Aug 2005
Posts: 37

PostPosted: Thu Aug 11, 2005 7:25 am    Post subject: Reply with quote

When can we expect PHP5 to be officially supported in portage? I'm waiting for that day before I install (it would be nice to install on my lappie as a testbed).
Back to top
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Thu Aug 11, 2005 11:29 am    Post subject: Reply with quote

tessmonsta wrote:

Appearently, the session extension has been disabled. After a few searches, it seems that I should add "session" to package.use

I'm just guessing, of course. :?


This is correct. The session extension now depends on the setting of the "session" USE flag. We made it possible to select/deselect almost anything from both PHP4 and PHP5. When the new Ebuilds will go into Portage we'll update the default profiles so that important flags that practically everyone wants like "session", "sysvipc", and others that are normally in a default PHP install will be automatically activated, so you don't have to worry too much that a simple install of PHP will give you a too stripped-down version of it. Of course you can then, if you don't need something, just disable it. :)

@ nautiazn85: We're currently going through a number of little bugs and updating corresponding, php-related Ebuilds in our overlay, after that's done we'll get the new Ebuilds into Portage, I daresay another week at least will be needed, but I'm not sure, that depends, if we find other problems we'll have to fix them and there are some things on our TODO list that need to be finished first. :)
_________________
Best regards, Luca.
Back to top
View user's profile Send private message
Plouj
n00b
n00b


Joined: 01 Mar 2005
Posts: 12

PostPosted: Fri Aug 12, 2005 12:29 pm    Post subject: Reply with quote

It was rather unclear to me wether I should emerge mod_php after following this howto. Before I did that I don't think my apache was loading the php module.

(I'm a noob, so I really don't know whats going on behind the scenes)
Back to top
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Fri Aug 12, 2005 3:28 pm    Post subject: Reply with quote

Plouj wrote:
It was rather unclear to me wether I should emerge mod_php after following this howto. Before I did that I don't think my apache was loading the php module.

(I'm a noob, so I really don't know whats going on behind the scenes)


No, mod_php is already installed by dev-lang/php if you activate either the "apache" or the "apache2" USE flags (depending on what version of Apache you're going to use).

There now also is a new site about all this new PHP-Overlay with more documentation, newer releases of the overlay with new features and a bug-tracking system if you have questions or find problems while installing the new PHP-Overlay (please post only _bugs_ or enhancement wishes in the bug-tracker, for normal support like "how do I do this or that?" refer to the documentation, post in this forum post here or come ask in #gentoo-apache on irc.freenode.net, thanks!). The site is: http://svn.gnqs.org/projects/gentoo-php-overlay/
_________________
Best regards, Luca.
Back to top
View user's profile Send private message
Boosty
n00b
n00b


Joined: 12 Aug 2005
Posts: 22
Location: The Netherlands

PostPosted: Fri Aug 12, 2005 7:32 pm    Post subject: Reply with quote

Hi there,

As a user new to Gentoo (never really used a distro other than Slackware) I have a few questions on this overlay. But I'll start off with something I ran into today:
The link to the tarball on http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/Downloads refers to /~stuart/php-overlay.tar.gz while this should actually be /~stuart/php/php-overlay.tar.gz . The current link returns a 404.

After I found the correct URL I started going with the wiki-article on installing this overlay:
http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/InstallOverlay

To give you a good view of what I'm trying to do:
My goal is to install both php4-cgi and php5-cgi together with Apache 1.3.x and use suPHP 0.6.0 with these.
I found a suphp ebuild on bugs.gentoo.org that mentioned this overlay to get this done.

Q1: The article mentions the following:
Quote:
Code:
USE="pdo" emerge dev-lang/php

After this you should be set, but don't forget to actually emerge php. ;)

"Don't forget to actually emerge php"?
But err, isn't the command that is mentioned before that line the way to emerge php?
Do you mean "do not forget to emerge apache."?

Q2: First time I emerged php4 and php5, I forgot to set the
Code:
ACCEPT_KEYWORDS="~amd64"

(it's a amd64, so no ~x86)
But both php4 and php5 emerged fine. What did I miss by not using this parameter?

I know that the keywords means that emerge can use ebuilds that aren't marked stable on amd64, but I believe that PHP5 was marked unstable. Why didn't emerge complain?

Q3: I replaced the
Code:
emerge dev-lang/php

by
Code:
emerge '=dev-lang/php-4*' '=dev-lang/php-5*'

because I want both.

In the example I see that this should emerge:
dev-libs/apr
dev-libs/apr-util
net-www/apache-2
dev-lang/php-5.1.0_beta-r3
But when I do my code, only php-4 and php-5 are installed without apache.
This isn't a problem; I can emerge apache seperately, but I'm curious: why didn't the dependecies show up here?

Hope someone could clarify these things for me. Thanks in advance for that. ;)

Don't worry if I messed things up; I'll start over on building after my questions are answered anyway :P
_________________
The nice thing about standards is that there are so many of them to choose from.
Back to top
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Fri Aug 12, 2005 8:11 pm    Post subject: Reply with quote

Boosty wrote:
Hi there,

As a user new to Gentoo (never really used a distro other than Slackware) I have a few questions on this overlay. But I'll start off with something I ran into today:
The link to the tarball on http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/Downloads refers to /~stuart/php-overlay.tar.gz while this should actually be /~stuart/php/php-overlay.tar.gz . The current link returns a 404.c


Welcome to Gentoo, and thanks for reporting this, was fixed now!

Boosty wrote:
After I found the correct URL I started going with the wiki-article on installing this overlay:
http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/InstallOverlay

To give you a good view of what I'm trying to do:
My goal is to install both php4-cgi and php5-cgi together with Apache 1.3.x and use suPHP 0.6.0 with these.
I found a suphp ebuild on bugs.gentoo.org that mentioned this overlay to get this done.


Just for info, the suPHP Ebuild is also in the official Portage tree as far as I know now.

Boosty wrote:
Q1: The article mentions the following:
Quote:
Code:
USE="pdo" emerge dev-lang/php

After this you should be set, but don't forget to actually emerge php. ;)

"Don't forget to actually emerge php"?
But err, isn't the command that is mentioned before that line the way to emerge php?
Do you mean "do not forget to emerge apache."?


Hmm that passage is not clear. I corrected it now in the docs. Thanks for pointing out.

Boosty wrote:
Q2: First time I emerged php4 and php5, I forgot to set the
Code:
ACCEPT_KEYWORDS="~amd64"

(it's a amd64, so no ~x86)
But both php4 and php5 emerged fine. What did I miss by not using this parameter?

I know that the keywords means that emerge can use ebuilds that aren't marked stable on amd64, but I believe that PHP5 was marked unstable. Why didn't emerge complain?


Well, unless you run your whole machine as ACCEPT_KEYWORDS="~amd64" in /etc/make.conf or if you first added "dev-lang/php" to /etc/portage/package.keywords, then emerge should have complained. If you did one of the two aforementioned things, then it's normal and expected that emerge will permit you to install dev-lang/php without problems.

Boosty wrote:
Q3: I replaced the
Code:
emerge dev-lang/php

by
Code:
emerge '=dev-lang/php-4*' '=dev-lang/php-5*'

because I want both.

In the example I see that this should emerge:
dev-libs/apr
dev-libs/apr-util
net-www/apache-2
dev-lang/php-5.1.0_beta-r3
But when I do my code, only php-4 and php-5 are installed without apache.
This isn't a problem; I can emerge apache seperately, but I'm curious: why didn't the dependecies show up here?


Hmm I just tested that with adding "-e" (--emptytree) to emerge, so that it simulates an emerge with the dependencies that would be installed if nothing else was installed on the system, and Apache was part of this. Did you add "net-www/apache" to /etc/portage/package.keywords? Are you sure you set the "apache2" USE flag while emerging your PHP? If yes, and if Apache isn't already installed, it should pull it in and install it before PHP...

Boosty wrote:
Hope someone could clarify these things for me. Thanks in advance for that. ;)

Don't worry if I messed things up; I'll start over on building after my questions are answered anyway :P


No problem. :) We appreciate testers that do frequent rebuilds, they spot more bugs. :P
_________________
Best regards, Luca.
Back to top
View user's profile Send private message
StifflerStealth
l33t
l33t


Joined: 03 Jul 2002
Posts: 968

PostPosted: Fri Aug 12, 2005 8:57 pm    Post subject: Reply with quote

Apache 2 is marked stable in the portage tree, so type as root:
Quote:
$ emerge info
and look at the use flag section. The flags should be in alphabetical order and look for the apache and apache2 flags. If you do not see apache, but you see apache2, you need to edit the file /etc/make.conf. In that file, find the USE="..." part and look for the apache2 flag. You need to change that from apache2 to apache. Then save and exit. Then type:
Quote:
emerge -uD world --newuse -p
to see if any of the packages need to be updated.

Also, since apache2 is stable and it seems like you don't intend to use it, can type this as root:
Quote:
echo net-www/apache-2* >> /etc/portage/package.mask
That will make sure that all apache 2 is now masked. Nothing should depend on it at this point. Also, you made to unmerge Apache2 before doing this, if it is installed.

EDIT: Oh, when I type your code, I get this:
Quote:
emerge '=dev-php/php-4*' '=dev-php/php-5*' -p

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[blocks B ] <=dev-php/php-4.99.99 (is blocking dev-php/php-5.0.4-r2)
[ebuild NSF ] dev-java/sun-jdk-1.4.2.09
[ebuild N ] app-crypt/mhash-0.9.2
[ebuild NS ] dev-php/php-4.4.0
[ebuild R ] dev-php/php-5.0.4-r2
It works, but there is a blocker and I have no idea where that comes from. :S NOTE: I cheated a little with the overlay. Since some packages are hard linked to depend on dev-php/php I copied all the files from dev-lang to dev-php and changed the ebuild to -r2 to override the version in portage which is -r1.
_________________
Nothing to read in this sig. Move along.
Back to top
View user's profile Send private message
Boosty
n00b
n00b


Joined: 12 Aug 2005
Posts: 22
Location: The Netherlands

PostPosted: Fri Aug 12, 2005 9:44 pm    Post subject: Reply with quote

CHTEKK wrote:
Just for info, the suPHP Ebuild is also in the official Portage tree as far as I know now.

Ah, my tree was last sync'ed on august 6. And the suPHP ebuild was added... august 6, just after I sync'ed ;)
Thanks for mentioning!

CHTEKK wrote:
Well, unless you run your whole machine as ACCEPT_KEYWORDS="~amd64" in /etc/make.conf or if you first added "dev-lang/php" to /etc/portage/package.keywords, then emerge should have complained. If you did one of the two aforementioned things, then it's normal and expected that emerge will permit you to install dev-lang/php without problems.

That explains.
I did list dev-lang/php in package.keywords, but I was under the impression that both actions were required for this to work out. Reading this part of the wiki again I can see where I went wrong.
Why not use
Code:
ACCEPT_KEYWORDS=~amd64 emerge <package> -p

just as you on the USE="pdo"? (suggested by a friend of mine)

CHTEKK wrote:
Boosty wrote:
But when I do my code, only php-4 and php-5 are installed without apache.
This isn't a problem; I can emerge apache seperately, but I'm curious: why didn't the dependecies show up here?

Hmm I just tested that with adding "-e" (--emptytree) to emerge, so that it simulates an emerge with the dependencies that would be installed if nothing else was installed on the system, and Apache was part of this. Did you add "net-www/apache" to /etc/portage/package.keywords? Are you sure you set the "apache2" USE flag while emerging your PHP? If yes, and if Apache isn't already installed, it should pull it in and install it before PHP...

I didn't add net-www/apache to /etc/portage/package.keywords , or use the apache2 USE flag while emerging.
But I think I already discovered the problem in the USE flag in /etc/make.conf , see below.

Quote:
No problem. :) We appreciate testers that do frequent rebuilds, they spot more bugs. :P

Thanks for your help, I'll try again tomorrow.

StifflerStealth wrote:
If you do not see apache, but you see apache2, you need to edit the file /etc/make.conf. In that file, find the USE="..." part and look for the apache2 flag. You need to change that from apache2 to apache.

Ah thanks. I did have "-apache2" in there, but no "apache" USE flag.
I'll see to it that my packages are updated to reflect the new USE flags.

StifflerStealth wrote:
Also, since apache2 is stable and it seems like you don't intend to use it, can type this as root:
Quote:
echo net-www/apache-2* >> /etc/portage/package.mask
That will make sure that all apache 2 is now masked. Nothing should depend on it at this point. Also, you made to unmerge Apache2 before doing this, if it is installed.

I had this set up slightly different:
/etc/portage/package.mask:
Code:
>=net-www/apache-2

I'll research the difference between your version and mine ;)

StifflerStealth wrote:
EDIT: Oh, when I type your code, I get this:
Quote:
emerge '=dev-php/php-4*' '=dev-php/php-5*' -p

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[blocks B ] <=dev-php/php-4.99.99 (is blocking dev-php/php-5.0.4-r2)
[ebuild NSF ] dev-java/sun-jdk-1.4.2.09
[ebuild N ] app-crypt/mhash-0.9.2
[ebuild NS ] dev-php/php-4.4.0
[ebuild R ] dev-php/php-5.0.4-r2
It works, but there is a blocker and I have no idea where that comes from. :S NOTE: I cheated a little with the overlay. Since some packages are hard linked to depend on dev-php/php I copied all the files from dev-lang to dev-php and changed the ebuild to -r2 to override the version in portage which is -r1.

When I was messing around with the overlay, I had a message like this (different version for the blocker) and I had to do a emerge -C php again to get rid of php, I'm not sure why though. I did check the emerge.log which indicated that I did do a emerge -C php before actually starting with the overlay.

Perhaps something like this is the case on your machine as well? (oh well, if it works, then why change it ;))
_________________
The nice thing about standards is that there are so many of them to choose from.
Back to top
View user's profile Send private message
StifflerStealth
l33t
l33t


Joined: 03 Jul 2002
Posts: 968

PostPosted: Sat Aug 13, 2005 12:04 am    Post subject: Reply with quote

Boosty wrote:
StifflerStealth wrote:
Also, since apache2 is stable and it seems like you don't intend to use it, can type this as root:
Quote:
echo net-www/apache-2* >> /etc/portage/package.mask
That will make sure that all apache 2 is now masked. Nothing should depend on it at this point. Also, you made to unmerge Apache2 before doing this, if it is installed.

I had this set up slightly different:
/etc/portage/package.mask:
Code:
>=net-www/apache-2

I'll research the difference between your version and mine ;)[/quote] Well, I forgot the '=' in front, so it should have been: =net-www/apache-2*
:oops:

There really is no difference between the two. The way I have it means that all packages with 2.x as a version, which means greater than or equal to version 2. ;) However, you can change mine to =net-www/apache-2.0* which will mask all version 2.0.x, so if version 2.1 ever comes out and you want to try that, it won't be masked.

Like I have in my package.unmask: =dev-php/php-5.0.4*
This way I do not get the 5.1 betas of php and only the 'stable' release.

Cheers.
_________________
Nothing to read in this sig. Move along.
Back to top
View user's profile Send private message
Boosty
n00b
n00b


Joined: 12 Aug 2005
Posts: 22
Location: The Netherlands

PostPosted: Sat Aug 13, 2005 4:24 pm    Post subject: Reply with quote

[edit]
Sorry, forgot that this wasn't the support forum. Perhaps my posts and the answers should be split to a new topic. If anyone can confirm the anomalies I report in this post, I'd be happy to make a bugreport.
[/edit]

I just emerged php4, php5 and apache 1.3 again. This time everything went exactly as described on the wiki page. That also includes using the eselect module to make the symlink.

The reason that apache didn't come with the emerge was (as mentioned by CHTEKK) because I didn't have the apache USE flag in /etc/portage/package.keywords . I only had the cgi USE flag (no cli, apache or apache2), because I didn't need the modules and thought they would conflict when emerging.

The configuration ended up in /etc/php/apache1-php4/ and I assume this is right when modules are build next to cgi binaries.

Here's a diff of the configurations (apache 1.3 had php4 installed as a module before it was unmerged to use the overlay, that's why there was a config already):
Code:
cingulate php-overlay # diff ._cfg0000_php.ini /etc/php/apache1-php4/php.ini
411c411,412
< include_path = ".:/usr/share/php"
---
> ;include_path = ".:/php/includes"
> include_path = ".:/usr/lib/php"
414c415
< include_path = ".:/usr/share/php"
---
> ;include_path = ".;c:\php\includes"
428c429
< extension_dir = /usr/lib64/php4/lib/php/extensions/no-debug-non-zts-20020429
---
> extension_dir = /usr/lib64/php/extensions/no-debug-non-zts-20020429
496a498,499
> ; allow_url_fopen = On
> ; Closed for security - <robbat2@gentoo.org>
535c538
< ; extension_dir directive above.
---
> ; extension_dir = /usr/lib64/php/extensions/no-debug-non-zts-20020429
cingulate php-overlay #

I noticed that include_path is changed from ".:/usr/lib/php" which doesn't exist on my system, to ".:/usr/share/php" which doesn't exist either. I do have /usr/lib/php[45] directories. Did something go wrong here, or is the "." path enough for cgi-php to find it's libs?
Also note that ".:/usr/share/php" is uncommented for both UNIX as Windows in the new config, while Windows was commented in the old one.
_________________
The nice thing about standards is that there are so many of them to choose from.
Back to top
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Mon Aug 15, 2005 5:25 pm    Post subject: Reply with quote

Boosty wrote:
I noticed that include_path is changed from ".:/usr/lib/php" which doesn't exist on my system, to ".:/usr/share/php" which doesn't exist either. I do have /usr/lib/php[45] directories. Did something go wrong here, or is the "." path enough for cgi-php to find it's libs?
Also note that ".:/usr/share/php" is uncommented for both UNIX as Windows in the new config, while Windows was commented in the old one.


Yes this is correct, the configuration underwent some major changes. The include_path is correct with ".:/usr/share/php", since the first . means "search the libs I need in the current directory where I (script) am being executed", and /usr/share/php points to the location where PEAR packages and so on would be installed. This directory is created and populated with stuff if you activate the "pear" USE flag, and/or if you emerge dev-php/PEAR-PEAR (please update to the latest overlay for this, a updated dependency needed to be put in for this to work). The /usr/lib/php[45] directories are totally correct, that's where the binaries and the modules from PHP get installed, the .php Libraries go into /usr/share/php like mentioned if you emerge PEAR packages for example. Also the fact that the include_path gets set two times to the exactly same thing is no problem, it all works the same and is normal as far as I can see because of the "sed" statement in the new Eclasses. No need to worry about that. ;)
_________________
Best regards, Luca.
Back to top
View user's profile Send private message
Boosty
n00b
n00b


Joined: 12 Aug 2005
Posts: 22
Location: The Netherlands

PostPosted: Thu Aug 18, 2005 3:30 pm    Post subject: Reply with quote

Alright.

I got my situation to work (mod_php4 + suPHP using php4 and php5) after altering the suPHP ebuild to work with apache 1.3. I'm experiencing a small problem which I hope to fix through compiling PHP with --enable-discard-path. I see no USE flags for this, is it a problem to use this options on this ebuild?
_________________
The nice thing about standards is that there are so many of them to choose from.
Back to top
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Thu Aug 18, 2005 4:08 pm    Post subject: Reply with quote

Boosty wrote:
I'm experiencing a small problem which I hope to fix through compiling PHP with --enable-discard-path. I see no USE flags for this, is it a problem to use this options on this ebuild?


Hi, there was no such USE flag because no one of us thought about that configure-switch. :) I just added the USE flag "discard-path" to the PHP Ebuilds that toggles "--enable-discard-path". The updated Ebuilds are available in the SVN repository or in the next hourly tarball. Have fun and thanks for reporting this, CHTEKK.

EDIT: Though I'm not sure this new option will solve your suPHP problems, I have heard of other people who have it running without this. The USE flag is just provided as another option, if it doesn't work with that option set, it probably isn't the fault of PHP but of some suPHP/Apache related configuration. :)
_________________
Best regards, Luca.
Back to top
View user's profile Send private message
Boosty
n00b
n00b


Joined: 12 Aug 2005
Posts: 22
Location: The Netherlands

PostPosted: Fri Aug 19, 2005 2:12 pm    Post subject: Reply with quote

CHTEKK wrote:
Hi, there was no such USE flag because no one of us thought about that configure-switch. :) I just added the USE flag "discard-path" to the PHP Ebuilds that toggles "--enable-discard-path". The updated Ebuilds are available in the SVN repository or in the next hourly tarball. Have fun and thanks for reporting this, CHTEKK.

Thanks for adding this. I just used the hourly overlay to remerge PHP (was using the official tarball before) and as the looks of it, it worked perfectly.

CHTEKK wrote:
EDIT: Though I'm not sure this new option will solve your suPHP problems, I have heard of other people who have it running without this. The USE flag is just provided as another option, if it doesn't work with that option set, it probably isn't the fault of PHP but of some suPHP/Apache related configuration. :)

The problem was gone after using the discard-path flag. I'm not sure if it's suPHP related, but it had to do with the way CGI handled PATH_INFO and PATH_TRANSLATED when using multiviews (it threw a "No input file specified.' message when attempting multiviews, which is a quite 'populair' error when using CGI). I believe Apache2 has a 'AcceptPathInfo On' directive to fix this, but apache1 doesn't.

I confirmed that it was the discard-path that made the difference by unmerging the PHP installed by the new overlay, and using the old overlay again.

Although everything looks fine, there are a few things I noticed while emerging, I'll leave it up to you guys to decide wether it's worth looking at ;)
I've included a single line before and after every error/warning to show it's position when compiling.

While configuring php-4.4.0 (CGI):
Code:
* Rebuilding configure script
configure.in:150: warning: AC_PROG_LEX invoked multiple times
autoconf/programs.m4:438: AC_DECL_YYTEXT is expanded from...
configure.in:150: the top level
>>> Source unpacked.

php-4.4.0 (CGI and apache1mod)
Code:
 *   Enabling ipv6
/usr/local/portage/eclass/php4-sapi-r1.eclass: line 314: java-config: command not found
 *   Disabling java
 *   Enabling jpeg-dir

php-5.0rc1 (CGI)
Code:
 * Rebuilding configure script
configure.in:141: warning: AC_PROG_LEX invoked multiple times
autoconf/programs.m4:438: AC_DECL_YYTEXT is expanded from...
aclocal.m4:2016: PHP_PROG_LEX is expanded from...
configure.in:141: the top level
>>> Source unpacked.

php-5.0rc1 (CGI and apache1mod)
Code:
checking for re2c... no
configure: WARNING: You will need re2c 0.98 or later if you want to regenerate PHP parsers.
checking for gawk... gawk

I was using the following USE flags:
Quote:
=dev-lang/php-4* -* apache bcmath bzip2 calendar cgi ctype crypt discard-path force-cgi-redirect ftp gif exif gd imagemagick imap innodb ipv6 jpeg memlimit mime mysql nls pdflib perl png posix session simplexml ssl sysvipc threads tiff truetype xml xml2 xsl zlib

(and same flags for php5)
_________________
The nice thing about standards is that there are so many of them to choose from.
Back to top
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Fri Aug 19, 2005 2:32 pm    Post subject: Reply with quote

Boosty wrote:

Thanks for adding this. I just used the hourly overlay to remerge PHP (was using the official tarball before) and as the looks of it, it worked perfectly.


Good to hear this.

Boosty wrote:

The problem was gone after using the discard-path flag. I'm not sure if it's suPHP related, but it had to do with the way CGI handled PATH_INFO and PATH_TRANSLATED when using multiviews (it threw a "No input file specified.' message when attempting multiviews, which is a quite 'populair' error when using CGI). I believe Apache2 has a 'AcceptPathInfo On' directive to fix this, but apache1 doesn't.
I confirmed that it was the discard-path that made the difference by unmerging the PHP installed by the new overlay, and using the old overlay again.


Ok thanks for the checking this. :) I never used MultiViews in Apache 1or 2, and I neither use much suPHP, tried it some time ago, but atm I use suEXEC+mod_fastcgi+PHP-cgi to serve .php pages.

Boosty wrote:

While configuring php-4.4.0 (CGI):
Code:
* Rebuilding configure script
configure.in:150: warning: AC_PROG_LEX invoked multiple times
autoconf/programs.m4:438: AC_DECL_YYTEXT is expanded from...
configure.in:150: the top level
>>> Source unpacked.



This is normal afaik, until only warnings show up there is nothing to fear, if it would crash or throw a fatal error, then we'd have a problem, but that never happened.

Boosty wrote:

php-4.4.0 (CGI and apache1mod)
Code:
 *   Enabling ipv6
/usr/local/portage/eclass/php4-sapi-r1.eclass: line 314: java-config: command not found
 *   Disabling java
 *   Enabling jpeg-dir



Ok, this was indeed a bug, or better a logic error in the php4-eclass. :) Fixed this now in the Overlay. Thanks for reporting this!

Boosty wrote:

php-5.0rc1 (CGI)
Code:
 * Rebuilding configure script
configure.in:141: warning: AC_PROG_LEX invoked multiple times
autoconf/programs.m4:438: AC_DECL_YYTEXT is expanded from...
aclocal.m4:2016: PHP_PROG_LEX is expanded from...
configure.in:141: the top level
>>> Source unpacked.



This is normal afaik, until only warnings show up there is nothing to fear, if it would crash or throw a fatal error, then we'd have a problem, but that never happened.

Boosty wrote:

php-5.0rc1 (CGI and apache1mod)
Code:
checking for re2c... no
configure: WARNING: You will need re2c 0.98 or later if you want to regenerate PHP parsers.
checking for gawk... gawk



This is normal afaik, until only warnings show up there is nothing to fear, if it would crash or throw a fatal error, then we'd have a problem, but that never happened. re2c is used afaik when regenerating PHP parsers, like it states there, but is not _needed_ to compile PHP, not how we do it anyway. If it would crash and throw a "Error: re2c is required blabla" then we'd have a problem, but it's only a warning about an option we don't even use and that is not needed.

Thank you again for reporting all of this and testing under Apache1, afaik no one ever did that since we all run Apache2. Heh, now we know it also works with Apache1! Thanks for your efforts, CHTEKK.
_________________
Best regards, Luca.
Back to top
View user's profile Send private message
Boosty
n00b
n00b


Joined: 12 Aug 2005
Posts: 22
Location: The Netherlands

PostPosted: Fri Aug 19, 2005 4:58 pm    Post subject: Reply with quote

CHTEKK wrote:
Boosty wrote:

Thanks for adding this. I just used the hourly overlay to remerge PHP (was using the official tarball before) and as the looks of it, it worked perfectly.

Good to hear this.

Sorry, I was mistaken.

The emerge did go well, but I managed to break something on my running configuration. I think I didn't notice it first because I forgot to restart apache directly afterwards.

After doing some tests I found out that I didn't have the PCRE USE flag set, thus preventing PCRE from being compiled. This caused one of our websites to stop functioning.
Strangely, the official overlay didn't have this problem (I confirmed this) althought I didn't have the PCRE flag set there either. I can't isolate the problem by searching though the ebuilds and eselects. Looking at the code, not setting the PCRE USE flag should have caused problems with the official overlay as well.

CHTEKK wrote:
Ok thanks for the checking this. :) I never used MultiViews in Apache 1or 2, and I neither use much suPHP, tried it some time ago, but atm I use suEXEC+mod_fastcgi+PHP-cgi to serve .php pages.

Which is a good solution, if you aren't on a multi-user system or if you trust everyone ;)

CHTEKK wrote:
Ok, this was indeed a bug, or better a logic error in the php4-eclass. :) Fixed this now in the Overlay. Thanks for reporting this!

No problem.

CHTEKK wrote:
Thank you again for reporting all of this and testing under Apache1, afaik no one ever did that since we all run Apache2. Heh, now we know it also works with Apache1! Thanks for your efforts, CHTEKK.

I will continue testing until the machine goes into production state. As far as I can tell the builds are fine for Apache1, if you get your USE flags right, that is.
_________________
The nice thing about standards is that there are so many of them to choose from.


Last edited by Boosty on Fri Aug 19, 2005 6:05 pm; edited 2 times in total
Back to top
View user's profile Send private message
llongi
Retired Dev
Retired Dev


Joined: 15 Apr 2004
Posts: 459
Location: Switzerland

PostPosted: Fri Aug 19, 2005 5:59 pm    Post subject: Reply with quote

Boosty wrote:

After doing some tests I found out that I didn't have the PCRE USE flag set, thus preventing PCRE from being compiled. This caused one of our websites to stop functioning.
Strangely, the official overlay didn't have this problem (I confirmed this) althought I didn't have the PCRE flag set there either. I can't isolate the problem by searching though the ebuilds and eselects. Looking at the code, not setting the PCRE USE flag should have caused problems with the official overlay as well.


This is correct. I found yesterday evening a typo in the function that enables/disables the PCRE regex, so it made no difference if you had the USE flag on or off, they were _always_ on, that wasn't acceptable for people or embedded systems where you need to disable everything that you can. So the typo was fixed and now the "pcre" USE flag does what it should do: enable/disable PCRE regex support. :)
The "official" Overlay tarball is old now, over a week, it misses _many_ important fixes that are in the SVN repository or in the hourly tarball, wich is much more up-to-date, stable and featureful than the "official" tarball. What will go next week into official Portage tree is the SVN repository. So I atm recommend using the hourly tarball, or even better if possible, the SVN repository directly.

Boosty wrote:

Which is a good solution, if you aren't on a multi-user system or if you trust everyone ;)


Why? I solved it that thanks to suEXEC the PHP-cgi runs as the user of the file, and also each user has his own php.ini where I define customized open_basedir, tmp_path and other settings. It's like suPHP in that aspect, imho just faster (at least version 0.5.X of suPHP was relatively slow since it always needed to load the PHP-cgi binary, compared to mod_fastcgi that has always some php-cgi-processes "on hold").

Boosty wrote:

I will continue testing until the machine goes into production state. As far as I can tell the builds are fine for Apache1.


Ok thanks, this helps us a lot. :) Thanks again, have a nice day, CHTEKK.
_________________
Best regards, Luca.
Back to top
View user's profile Send private message
Boosty
n00b
n00b


Joined: 12 Aug 2005
Posts: 22
Location: The Netherlands

PostPosted: Fri Aug 19, 2005 6:41 pm    Post subject: Reply with quote

CHTEKK wrote:
This is correct. I found yesterday evening a typo in the function that enables/disables the PCRE regex, so it made no difference if you had the USE flag on or off, they were _always_ on, that wasn't acceptable for people or embedded systems where you need to disable everything that you can. So the typo was fixed and now the "pcre" USE flag does what it should do: enable/disable PCRE regex support. :)

Aha, good to have it fixed and now I know what the problem was exactly. :)

CHTEKK wrote:
Why? I solved it that thanks to suEXEC the PHP-cgi runs as the user of the file, and also each user has his own php.ini where I define customized open_basedir, tmp_path and other settings. It's like suPHP in that aspect, imho just faster (at least version 0.5.X of suPHP was relatively slow since it always needed to load the PHP-cgi binary, compared to mod_fastcgi that has always some php-cgi-processes "on hold").

I'll take back my last statement; I always was under the impression suPHP offered a slightly different approach to it's security making it more appropriate for webhosting services.
But I do believe suExec has a few drawbacks that makes it less managable on servers with a lot of vhosts, and it's configuration prone to small errors. CGI normally already confuses me (I can get it work, but I don't have a clue what I've done afterwards) and I'd like a more transparent setup with suPHP.
In addition, I believe that suExec normally needs a separate binary for every user and it needs extra fixes to make PHP scripts run without #!/path/to/phpcgi in the head.

Now, if the suPHP build could be fixed to work with apache1 out of the box, my configuration is as good as complete and consistent :) If we reach a point where suPHP gets to slow, I can still consider using suExec.

Oh fyi; all testing is done on a amd64 dual-opteron system.
_________________
The nice thing about standards is that there are so many of them to choose from.
Back to top
View user's profile Send private message
piercey
Apprentice
Apprentice


Joined: 28 Jan 2005
Posts: 182

PostPosted: Sun Aug 21, 2005 2:48 am    Post subject: Reply with quote

Hey guys,

Has anything been sorted out yet to get the mysql pdo extension (and others) loaded? All I can seem to get is the sqlite driver :\
_________________
[ 2008.0 X86 E8400 @ 4.0Ghz ]
Back to top
View user's profile Send private message
ddd
n00b
n00b


Joined: 28 Dec 2004
Posts: 46

PostPosted: Sun Aug 21, 2005 9:23 am    Post subject: Re: HOWTO Install PHP5 Reply with quote

ScriptBlue wrote:

Add the following line to make.conf and promptly remove it after installing PHP5
Code:
ACCEPT_KEYWORDS="~x86"



I have removed it, but now it wants to install old version?

How to fix it?

Code:
# /usr/bin/emerge -upv world

These are the packages that I would merge, in order:

Calculating world dependencies ...done!
[blocks B     ] dev-libs/apr-util (is blocking net-www/apache-2.0.54-r9)
[blocks B     ] dev-libs/apr (is blocking net-www/apache-2.0.54-r9)
[ebuild     UD] net-www/apache-2.0.54-r9 [2.0.54-r14] +berkdb -doc +gdbm +ipv6 -ldap (-selinux) +ssl -static -threads 33 kB

Total size of downloads: 33 kB
[/quote]
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum