I'm aware of bugs: #220519 and #212777. This bug is not about PECL extension in portage but about being able to compile manually any PECL extension using just: $ phpize && ./configure && make && sudo make install Most, if not all, PECL extensions fail at ./configure time with: /path/to/a/pecl/extension/libtool: line 467: CDPATH: command not found /path/to/a/pecl/extension/libtool: line 1152: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6b, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b libtool: and run autoconf again. make: *** [apm.lo] Erreur 63 The problem is that PHP being built with libtool 2.2, the phpize command will install into the extension directory a script called "libtool" which will fail with the above error. The real fix behind this problem is IMHO not about doing some magic in PECL ebuilds but about compiling PHP with sys-devel/libtool:1.3
First of all, all versions below 2.2.6b are vulnerable. Secondly you likely need to delete lt*.m4 and libtool.m4 from the source packages you are compiling, and running autoreconf on them. And last, none of these failing packages are in portage as you said, so closing...
There is no such thing as lt*.m4 or libtool.m4. libtool-1.4 is normally required to have a sane PHP setup: http://php.net/svn.php but libtool-1.3 is also fine. The important thing is to not use libtool >= 1.5 while compiling php. The problem relies in the fact that /usr/bin/phpize is broken: it creates a 'libtool' file which is not correct inside a PECL package and prevents it to be build. While installing dev-lang/php I expect to have a working phpize command I can use with any PECL extension, not just the one provided in portage. A supported extension like xdebug is failing the same way: /home/patrick.allaert/Projets/xdebug/libtool: line 467: CDPATH: command not found /home/patrick.allaert/Projets/xdebug/libtool: line 1152: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6b, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b libtool: and run autoconf again. make: *** [xdebug.lo] Error 63 Please, I kindly ask you to reconsider this issue before closing it. It is has reporting an issue regarding "make" not being able to compile any C program and closing it because this program is not part of portage :(
libtool-1.3.5 in portage is not for building, it's for old binary-only applications, it doesn't install headers or symlink to libltdl.so, it only installs certain .so version of libltdl and that's it moving to php maintainers...
(In reply to comment #3) > moving to php maintainers... Thanks :) For now, I always mask >=sys-devel/libtool-1.5 before recompiling php and unmask it again right after. A possible alternative is maybe not to depend on sys-devel/libtool:1.3 but patching /usr/bin/phpize so that it generates libtool-1.3 like files.
(In reply to comment #4) > (In reply to comment #3) > > moving to php maintainers... > > Thanks :) > > For now, I always mask >=sys-devel/libtool-1.5 before recompiling php and > unmask it again right after. > > A possible alternative is maybe not to depend on sys-devel/libtool:1.3 but > patching /usr/bin/phpize so that it generates libtool-1.3 like files. > Well, this worked before, but it appears I can't compile PHP anymore using sys-devel/libtool:1.3: $ sudo emerge php Calculating dependencies... done! !!! All ebuilds that could satisfy ">=sys-devel/libtool-2.2.6b" have been masked. !!! One of the following masked packages is required to complete your request: - sys-devel/libtool-9999 (masked by: package.mask, missing keyword) - sys-devel/libtool-2.2.6b (masked by: package.mask) (dependency required by "dev-lang/php-5.2.13" [ebuild]) (dependency required by "php" [argument]) If someone can point me to a temporary workaround to compile PHP with a lower libtool version I could manage to provide a patch that could possibly fix phpize.
There is no problem, except the one you've created yourself. If you want to compile php extensions from source, you need to learn a bit more about autotools - I'm nearly certain that far over 90% of those extensions builds just fine with libtool 2, with very little more work than removing old libtool macros and running autoreconf. Have a look at /usr/portage/eclass/php-ext-source-r1.eclass, specifically php-ext-source-r1_phpize. (OK, so I *do* dislike the way php upstream "solves" certain problems)
(In reply to comment #6) > There is no problem, except the one you've created yourself. > > If you want to compile php extensions from source, > you need to learn a bit more about autotools > - I'm nearly certain that far over 90% of those extensions > builds just fine with libtool 2, with very little more work than > removing old libtool macros and running autoreconf. That's what I tried to say in Comment #1 but failed; thanks for clearing it up. Temove old .m4 files, looks like aclocal.m4 is one candidate too. Fix configure.ac or configure.in from uncompatible calls to libtool. Run autotools (autorecofn) on the package. And the problem is solved.
(In reply to comment #6) > There is no problem, except the one you've created yourself. > > If you want to compile php extensions from source, > you need to learn a bit more about autotools > - I'm nearly certain that far over 90% of those extensions > builds just fine with libtool 2, with very little more work than > removing old libtool macros and running autoreconf. > > Have a look at /usr/portage/eclass/php-ext-source-r1.eclass, > specifically php-ext-source-r1_phpize. > > (OK, so I *do* dislike the way php upstream "solves" certain problems) Well, being a PHP extension developer, I'm using my favorite Linux distribution to do it which requires extra steps which are not documented. I'm confirming here that: $ phpize $ rm aclocal.m4 && autoreconf $ ./configure $ make is a valid workaround. Trying to be as objective as possible, I see two issues here: 1° PHP should try to cope with decent version of libtool, autoconf, automake,... 2° Gentoo maintainers should try to respect PHP's building requirements Both issues are contradictory but have valid reasons not being addressed.
The problem is that phpize is trying to be both smarter than autoreconf and *too* backward compatible - i.e. autoconf 2.1 series are considered completely obsoleted by its upstream. This is (IMHO) exercise in futility. Also, it seems phpize has still not been updated to work properly with libtool 2 (it cats only libtool.m4 - that may not be enough). There's also the fact, that 'cat acinclude.m4 ./build/libtool.m4 > aclocal.m4' stopped being a good idea a few versions of automake ago.
*** Bug 395787 has been marked as a duplicate of this bug. ***
