php.eclass has this line (291) myconf="${myconf} --with-mysqli=/usr changing this to myconf="${myconf} --with-mysqli=/usr/bin/mysql_config fixes the problem. Reproducible: Always Steps to Reproduce:
We currently don't have mysql 4.1 in Portage. For the moment, I've disabled mysqli support in php5. When mysql 4.1 is added, I'll look at this again. Best regards, Stu
As I need (and use) >=mod_php-5, >=myslq-4.1 for my work. Please let me know if I can help to speed up things a bit. Testing, bug hunting or just hacking together an ebuild or two shouldn't be a problem for me.
Created attachment 35954 [details, diff] mysqli patch for php5-sapi This patch enables mysqli and enbales mysqli and mysql to coexist.
Sorry, but I can't include that patch for the moment. Our QA tools will reject the ebuild, because a) it depends on a package that isn't yet there b) the dep (if it was there) won't be stable (prevents php ebuilds being marked stable) Sorry, Stu
no problem, just uploaded it for later reference, and for people who needs it.
It's much appreciated. We'll need it once MySQL 4.1 goes into the tree. Thanks, Stu PS: I've fixed the mod_php and php5-sapi_pkg_preinst() bug. Thanks for that one.
Created attachment 39181 [details, diff] mysqli patch for php5-sapi.eclass Synced the patch with the curent php5-sapi.eclass
I made a similar patch for a bug on mysql, but I had to put: enable_extension_with "mysql" "mysql" 0 "/usr/lib/mysql" and enable_extension_with "mysqli" "mysqli" 0 "/usr/bin/mysql_config" respectively, in order to make them co-exist. All the other changes are identical to yours. Without those extra values I get an error while compiling. Strange that it works for you, hmm? The bug I posted it in is 62582 by the way.
Another thing: MySQL 4.1 recently got added to the portage tree, although package.mask'ed.
Created attachment 44313 [details, diff] php5-sapi-mysqli.patch Update. Compiles for me with the mysql-4.1.7 in portage and mod_php-5.0.2.
As mysql is in portage, I reopened this bug.
works for me with the patch. bot i do have a few issues using the mysqli extension.
what issues would that be?
Created attachment 44488 [details, diff] PHP5 eclass patch to allow mysql and mysqli to coexist --with-mysql must have the path specified in order for the install not to die in the configure stage. I specified it for mysql and mysqli to be safe.
Created attachment 44490 [details, diff] php5-sapi.eclass.patch to allow USE="mysql mysqli" Sorry, the last patch was not in a unified diff format.
I based my patch on the installation notes from the PHP manual. Could you point me to the contradicting information? From: <http://se.php.net/manual/en/ref.mysqli.php> "Installation To install the mysqli extension for PHP, use the --with-mysqli=mysql_config_path/mysql_config configuration option where mysql_config_path represents the location of the mysql_config program that comes with MySQL versions greater than 4.1. If you would like to install the mysql extension along with the mysqli extension you have to use the same client library to avoid any conflicts." From: <http://se.php.net/manual/en/ref.mysql.php> " For compiling, simply use --with-mysql=[DIR] where [DIR] points to your MySQL installation directory. This MySQL extension doesn't support full functionality of MySQL versions greater than 4.1.0. For that, use MySQLi. If you would like to install the mysql extension along with the mysqli extension you have to use the same client library to avoid any conflicts. "
*** Bug 71725 has been marked as a duplicate of this bug. ***
@John Nilsson: The issue is that 2 out of 3 apps using mysqli dont work. phpMyAdmin is one of them. I just get a blank page without any error message. The 2nd one is a CMS i am working at. I get the same issue as with phpMyAdmin. But a 2nd Script of my own does work with mysqli perfectly.
I've had issues with phpMyAdmin and mysqli there are som bugs with specific versions of mysql. Can you rule out user error?
To clarify the above: The problem with phpmyadmin was that you can't execute a new query without freeing the previous result.
Since MySQL 4.1.7 has been added to portage, why don't we notify the maintainer that it's there so he can fix the php5-sapi.eclass?
Please do NOT add people that are already on mail aliases. Getting duplicate emails doesn't help with the slew of email we recieve already. This patches turn will come. It should definetly be possible for users to try repoman and their systems, and in doing so, they would have found the following output from it, when scanning php with the patch applied to the eclass. First the fatal errors (that prevents me from checking things in) DEPEND.bad 13 dev-php/php/php-5.0.1.ebuild: ~x86 ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.1.ebuild: ~ppc ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2-r1.ebuild: ~arm ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2-r1.ebuild: ~hppa ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2-r1.ebuild: ~ia64 ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2-r1.ebuild: ~ppc ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2-r1.ebuild: ~x86 ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2.ebuild: ~arm ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2.ebuild: ~hppa ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2.ebuild: ~ia64 ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2.ebuild: ~ppc ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.2.ebuild: ~x86 ['>=dev-db/mysql-4.1.7'] dev-php/php/php-5.0.0-r1.ebuild: ~x86 ['>=dev-db/mysql-4.1.7'] ... (and after this a few warnings caused by these) Simply put, it will not let me put the patch in until the new mysql is available in ~arch.
So because mysql 4.1 is package.mask'd as well as ~arch masked, repoman is upset?
The fix on repoman being upset, is simply to comment out line 186 of /usr/portage/profiles/package.mask. Since you were the one that added that line, Robbat2, I'm sure repoman wouldn't be upset if you removed it... Which would fix the breakage that you commented recently. So: What me worry?
what breakage is this you speak of? I am _not_ unmasking mysql4.1 at this point. I believe migration on upgrade is still not at an acceptable level for me, and it isn't stable enough for me yet. It will come out of package.mask eventully, probably with one of the newer versions (I haven't tested 4.1.8 yet). Repoman is rightfully upset as having that patch in would break the build for anybody that hase USE=mysqli and doesn't have mysql-4.1 in their package.unmask. The only alternative to this is to leave mysqli out of the DEPEND statement, and put the rest of the patch in, but that would open the way for the build breaking for users with only USE=mysqli (those that just put in USE flags without any realization of what they entail).
Just for the record, MySQL 4.1 is now concidered ready for production use.
Isn't it a bug in portage/repoman that you can't have a stable package depend on a non stable package with a non-default local USE-var?
why can't the php ebuild temporarily ignore the useflag that it doesn't work with? or not allow php5 to be built if it can't work with my useflags... Should dev-portage be added to this bug?
Created attachment 50678 [details] patch to php5-sapi.eclass to permit USE="mysql mysqli" This patch make use of mysql_config for both the extensions mysql-4.0.22 (oldest in portage tree) install it. Using both extension work but disable embedded mysql. I vaguely remember that php-5.0 don't work with mysql-3, maybe I'm wrong
interesting.. it does build, but when actually using mysqli, apache segfaults.. like when using mysqli in phpmyadmin... [Mon May 02 01:29:20 2005] [notice] child pid 17444 exit signal Segmentation fault (11) not that fun, anyone got experience on that one? AMD64 mod_php-5.0.3-r2.ebuild (uses the -r1 eclass) with the patch from comment #29 mysql-4.1.11 apache-2.0.53
cflags?
i'll just give emerge info, should contain everything: Portage 2.0.51.20-r5 (default-linux/amd64/2005.0/no-multilib, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.10-gentoo-r6 x86_64) ================================================================= System uname: 2.6.10-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 2800+ Gentoo Base System version 1.6.11 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.3 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks strict" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/" LANG="en_US" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 acpi apache2 authdaemond berkdb crypt curl fam flash fortran ftp gd gif gpm imap innodb ipv6 jp2 jpeg libwww lzw lzw-tiff maildir ming mp3 mysql mysqli ncurses nls oss pam pam-mysql pdflib perl php png python readline sasl session ssl tiff truetype usb userlocales vhosts xml2 xrandr zlib userland_GNU kernel_linux libc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS
ATTENTION: after many builds, i saw: http://bugs.php.net/bug.php?id=32282 the bug is fixed in 5.0.4 CVS ! i made a quick 5.0.4.ebuild, downloaded the CVS snapshot, renamed it to php-5.0.4.tar.bz2, put it in /usr/portage/distfiles, emerged mod_php now it finally works without segfaults. this is a known bug, so watch out when making a real 5.0.4.ebuild that you somehow emerge the CVS source, and not the upstream 5.0.4.tar.bz2 from php.net/dstrib. Hope that helps, Jax
PHP 5.0.4 is in portage now, closing.
* * We currently do not support the mysqli extension * Support will be added once MySQL 4.1 has been added to Portage * !!! ERROR: dev-php/mod_php-5.0.4 failed. !!! Function php5-sapi-r2_check_awkward_uses, Line 128, Exitcode 0 !!! mysqli not supported yet !!! If you need support, post the topmost build error, NOT this status message.
Yeah, this block is hard-coded and doesn't just go away when the right version of PHP is in portage. Also, not permitting both mysql and mysqli at once is a (slightly) different bug to be fixed (by using the patches attached to this bug).
Maybe I am mistaken, but: COuld not at least just a warning be displayed that it is highly unlikely to work if mysql<4.1 is installed instead of just blocking it? Of course 4.1 needs to go stable first, but this way it would at least allow people to install php5.0 with mysqli without having to patch the eclass.
It's still not enough to just enable them both, since it will complain that it's not possible to do so with bundled libs. It's necessary to change the php5-sapi.eclass like like this: enable_extension_with "mysql" "mysql" 1 -- to --> enable_extension_with "mysql" "mysql" 0 "/usr/lib/mysql" and enable_extension_with "mysqli" "mysqli" 1 -- to --> enable_extension_with "mysqli" "mysqli" 0 "/usr/bin/mysql_config" in order to make it work. Bug #83931 is a duplicate of this, really.
I've enabled mysqli support for mod_php 5.0.4. However, please note that this extension is known to segfault, and we're still waiting for a php-5.0.5 release to fix this. Adding this support means that php-5 cannot be marked stable until mysql-4.1 is marked stable. Best regards, Stu
*** Bug 83931 has been marked as a duplicate of this bug. ***
Hi, With USE="mysql mysqli" the newest PHP5 wants to downgrade my MySQL to 4.0.x And why is mysql 4.1 not considered stable at all? Its stable upstream for more than a half year.
You'll have to ask our mysql maintainers why MySQL-4.1 isn't considered stable on Gentoo yet. Anyway, it's all a bit academic. I've switched off support for mysqli again, as it broke our QA rules. I'll switch it back on once mysql-4.1 is in ~arch. Best regards, Stu
btw: USE="mysql" builds fine with 4.1 so the dep on mysql should be updated too (>=mysql-4.0)
(In reply to comment #41) > Hi, > With USE="mysql mysqli" the newest PHP5 wants to downgrade my MySQL to 4.0.x > And why is mysql 4.1 not considered stable at all? Its stable upstream for more > than a half year same problem here but with only mysql in USE flags
*** Bug 95150 has been marked as a duplicate of this bug. ***
Yes, please do not downgrade MySQL to 4.0.*. At the moment, MySQL 4.1 works fine here with the mysql extension, and since it works, there is no reason to bar people from using the features MySQL 4.1 provides. Thanks.
I've switched on mysqli support for the php-5.1-beta packages. Best regards, Stu
It still wants to downgrade mysql to 4.0.24
Yes, because php5-sapi-r3.eclass still has: mysql? ( =dev-db/mysql-4.0* ) In the DEPEND clause.
So why don't you update the MySQL dependency of php-sapi? This is really annoying, and meantime many people here, in bug #95150 and in the forums have requested this change.
Actually php5-sapi-r3 has mysql? ( dev-db/mysql ) mysqli? ( >=dev-db/mysql-4.1 ) but the php5-* ebuilds still depend on php5-sapi-r2
my mistake. mod_php depends on php5-sapi-r2.eclass, php is fine.
I just resynced my portage php5 only have 2 version of mod_php, mod_php-5.0.4 mod_php-5.1.0_beta, they both use php5-sapi-r2.ebuild, which still depend on mysql-4.0, thus can not use mysqli. Yes, there is a php5-sapi-r3.eclass use mysql-4.1 when mysqli was set, but at this time, NONE of these mod_php-5 use this eclass. BTW, WHY mod_php above version 5 ALWAYS want to use a testing apache2???? if somebody want zts, just use threads in apache2, then will build apache2 with mpm-worker. Then we can use zts in mod_php. I can not figure out any reason for mod_php-5.x to use a new testing apache2. PLEASE~~~, fix this restriction, and also fix the mysql-4.0 depend.
I was modify php-5.0.4-r1 ebuild to use php5-sapi-r3.eclass. I can compile php with mysql and mysqli (mysql-4.1.12). It's works fine for me (amd64).
I got it! Just modify 2 files 1. /usr/portage/eclass/depend.apache.eclass just change line 94 to APACHE2_DEPEND=">=net-www/apache-2.0.54-r7" 2. /usr/portage/eclass/php5-sapi-r2.eclass change line 67 to mysql? ( >dev-db/mysql-4.1* ) and remove those mysqli warning after line 153 then emerge metadata after these, u can emerge mod_php-5.0.4 without depend on testing apache2-2.0.54-r10 or apache-2.0.54-r11, and also can be build with mysql-4.1
modifying the eclasses directly is not the right way. They will be overwritten with the next emerge --sync. you could copy them over to your portdir overlay and modify them there but that didnt work for me. i changed the 5.1 beta ebuild to use the r3 eclass but that resulted in a epatch warning. and apache 2 testing... well. you want to use a hard-masked php and a hard-masked mysql but you dont want to use a testing apache2? doesnt make sense to me.
i have "porteted" the php 5.0.4 ebuild to the php5-sapi-r3.eclass and NO problems arch: x86 (tested on 2 gentoo maschines athlon and pentium M)
Why hasn't mod_php_5.1.0-beta been modified to support mysqli, too?
why not want testing apache?? because both php-5 and mysql-4.1 have so many new features I want, but there is no new features between stable apache2 and testing apache2, except that testing apache2 have more experimental mpm, but I only need mpm-worker for thread.
I just copied the 5.1 ebuild to my portage overlay and modified it to use the -r3 eclass. You have to copy all the patches from the files directory over to your overlay too, otherwise you'll get an epatch error. Then do a digest on the ebuild. Builds and works perfectly with mysqli only (no mysql) on my ~x86 system.
Ok, the 'mysqli' (Improved extension), which depends on MySQL 4.1, may be disabled, but why the classic 'mysql' extension depends strictly on MySQL 4.0*??? The standard mysql extension works flawlessly on MySQL 4.1 too...
Created attachment 64826 [details, diff] Enable Standard MySQL 4.1 Extension with PHP 5.0 This patch enables php-5.0* with mysql-4.1* using the standard MySQL extension ('mysql' USE flag, not 'mydqli').
