| Summary: | dev-php5/php-gtk-2.0.0: provides libtool version errors while trying to compile | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kfir Ozer <kfirufk> |
| Component: | New packages | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 220519 | ||
| Attachments: | build.log | ||
|
Description
Kfir Ozer
2008-07-21 06:58:31 UTC
This is not-quite duplicate of bug 220519 (it was expected that this may eventually surface). Anant, can you please take a look? I've been trying to fix this for some hours now and decided to give up. Apparently they are emulating autotools behaviour partly in their own build scripts (at least aclocal)... Just curious, what was already tried. My first guess would be to use php-ext-source-r1_phpize instead of buildconf and to move it to src_unpack (as QAs advise). I'm looking at the online cvs tree, not on the tarball, so I may be wrong, but buildconf creates aclocal.m4 by cat acinclude.m4 ./build/libtool.m4 php_gtk.m4. Somehow I don't think build/libtool.m4 gets updated, so this may be the origin of the bug. (In reply to comment #3) > Just curious, what was already tried. > My first guess would be to use php-ext-source-r1_phpize instead > of buildconf and to move it to src_unpack (as QAs advise). Yeah, that was indeed the first thing I tried, and eautoreconf failed with undefined references to certain M4 macros, namely GLIB_* and autoconf-related (why would those not be available!?). (In reply to comment #4) > I'm looking at the online cvs tree, not on the tarball, > so I may be wrong, but buildconf creates aclocal.m4 by > cat acinclude.m4 ./build/libtool.m4 php_gtk.m4. > Somehow I don't think build/libtool.m4 gets updated, so this may be the origin > of the bug. Yes, it's the same in the released version and this file (which is "generated" by phpize) is indeed not touched by elibtoolize/eautoreconf. Manually copying might work, but I doubt that this would be the correct solution... (In reply to comment #5) > (In reply to comment #3) > > Just curious, what was already tried. > > My first guess would be to use php-ext-source-r1_phpize instead > > of buildconf and to move it to src_unpack (as QAs advise). > Yeah, that was indeed the first thing I tried, and eautoreconf failed with > undefined references to certain M4 macros, namely GLIB_* and autoconf-related > (why would those not be available!?). To be exact, I saw these messages: http://bugs.php.net/bug.php?id=27630 The "fix" in CVS is this cat hack, so... still no idea how to fix this in the autotools-style (and I won't dare asking upstream as they simply want you to use only certain versions of autotools/libtool etc.). Frankly, phpize is sort of broken anyway wrt. libtool 2, as it cats only libtool.m4 (meaning it missed those other macros, that are now in separate files). What scares me most is the fact that they're thinking about replacing autotools with cmake. But, unless I'm missing something, those macros, you mentioned are in php_gtk.m4. Would you mind posting build.log of that failed attempt and the exact error messages from autotools ? Maybe simply setting AT_M4DIR to a correct value will be enough. Created attachment 161059 [details]
build.log
Looks like I need to be a bit more specific:
I think following should work:
don't run buildconf, run php-ext-source-r1_phpize instead,
but set AT_M4DIR=${S} (I'm just not sure, if this can be simply set
or will php-ext-source-r1_phpize have to be inserted verbatim, with
AT_M4DIR set in the eautoreconf line.
As far as I can tell, buildconf does only:
1. phpize (which is more or less correct, at least it would be,
if not for PHP_AUTOCONF=\"touch configure\" PHP_AUTOHEADER=\"touch config.h.in\"
part that may affect eautoreconf)
2. runs make on build2/build.mk, which tries to regenerate configure in a way,
that incompatible with eautoreconf, cause it cats build2/libtool.m4, which
AFAICT doesn't get updated to libtool 2
so ltmain.sh gets updated, but the macro is still old, and we get this bug.
I did exactly as you said and php-gtk compiled properly!
I replaced buildconf with php-ext-source-r1_phpize and i add AT_M4DIR=${S} at the beginning of the ebuild.
thanks!
do you need me to provide any other information ?
(In reply to comment #9) > Looks like I need to be a bit more specific: > I think following should work: > don't run buildconf, run php-ext-source-r1_phpize instead, > but set AT_M4DIR=${S} (I'm just not sure, if this can be simply set > or will php-ext-source-r1_phpize have to be inserted verbatim, with > AT_M4DIR set in the eautoreconf line. Indeed, this works. Thank you very much! =) (Just committed php-gtk-2.0.1 with the fix) I additionally overrode PHP_AUTO{CONF,HEADER} with "true" to silence the errors. The call to autoconf/autoheader by phpize is unncessary anyway, as we run eautoreconf later. No idea if this is generally true and we could optimize out that part in the eclass already. But as I don't plan on breaking anything again.... ;) |
