Summary: | dev-lang/php-5.2.14: Failed to emerge (undefined reference to `iconv') | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Denis I. Polukarov <dipolukarov> |
Component: | FreeBSD | Assignee: | Gentoo/BSD Team <bsd+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ava, cnyegle, nigoro.dev, php-bugs, prefix |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | FreeBSD | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 401067 | ||
Attachments: |
The complete build log
The ebuild environment file emerge --info =dev-lang/php-5.2.14 emerge -pqv =dev-lang/php-5.2.14 php-freebsd.patch php-5.4.0-libiconv.patch |
Description
Denis I. Polukarov
2011-04-19 14:51:28 UTC
Created attachment 270547 [details]
The complete build log
Created attachment 270549 [details]
The ebuild environment file
Created attachment 270551 [details]
emerge --info =dev-lang/php-5.2.14
Created attachment 270553 [details]
emerge -pqv =dev-lang/php-5.2.14
Keyworded =dev-lang/php-5.3.6 failed to build on "undefined reference to 'iconv' " too. FYI, I corrected this problem on my overlay several days ago. However, it is still testing. Please check following URL if you want to test it now. https://github.com/nigoro/amd64-fbsd/commit/e08434015754ade48b3170495c4e73e9e7c1ca45.diff Additionally, there are some packages where other I have not reported on the bug yet in overlay. Please check it if you are interested. https://github.com/nigoro/amd64-fbsd/ Thanks in advance. This problem exists in Gentoo-prefix for Linux too. PHP team, (& cc prefix team) Could you take a look at the patch above please? I've confirmed the patch make it (at least) build on x86-fbsd 8.2. (It doesn't pass test cases) Created attachment 294149 [details]
php-freebsd.patch
Rebased patch on current portage tree.
(In reply to comment #9) > Created attachment 294149 [details] > php-freebsd.patch > > Rebased patch on current portage tree. ping! any comments? Why not enable libiconv for all platforms that don't have iconv in their libc? (e.g. !elibc_glibc)? My src_configure-v2.eblit already contains phpconfutils_extension_with "iconv" "iconv" 0 "${EPREFIX}/usr" (without conditional) -- maybe this is a Prefix-local change, but if not, your patch looks redundant. (In reply to comment #11) > Why not enable libiconv for all platforms that don't have iconv in their libc? > (e.g. !elibc_glibc)? > > My src_configure-v2.eblit already contains > phpconfutils_extension_with "iconv" "iconv" 0 > "${EPREFIX}/usr" > (without conditional) -- maybe this is a Prefix-local change, but if not, your > patch looks redundant. We do not have this line in gentoo-x86. Besides, the newer src_configure eblits use $(use_with iconv iconv ) instead of the custom function from phpconfutils. Just let me know what lines I should add and I can review/fix it asap. Created attachment 307489 [details, diff]
php-5.4.0-libiconv.patch
I got the real problem. This shoud be PHP configure bug.
php-5.4.0/acinclude.m4:
dnl
dnl Check libc first if no path is provided in --with-iconv
dnl
if test "$PHP_ICONV" = "yes"; then
AC_CHECK_FUNC(iconv, [
found_iconv=yes
],[
AC_CHECK_FUNC(libiconv,[
PHP_DEFINE(HAVE_LIBICONV,1,[ext/iconv])
AC_DEFINE(HAVE_LIBICONV, 1, [ ])
found_iconv=yes
])
])
fi
This code actually check iconv or libiconv not only for libc, but also
$LIBS already set.
As Denis and I enabled libxml2, php added `xml2-config --libs` to
$LIBS, leading to confuse the test above.
Once $found_iconv set to "yes", php skip the test below and
ICONV_ALIASED_LIBICONV undefined.
php-5.4.0/acinclude.m4:
dnl
dnl Check external libs for iconv funcs
dnl
if test "$found_iconv" = "no"; then
<snip>
PHP_CHECK_LIBRARY($iconv_lib_name, libiconv, [
found_iconv=yes
PHP_DEFINE(HAVE_LIBICONV,1,[ext/iconv])
AC_DEFINE(HAVE_LIBICONV,1,[ ])
PHP_DEFINE([ICONV_ALIASED_LIBICONV],1,[ext/iconv])
AC_DEFINE([ICONV_ALIASED_LIBICONV],1,[iconv() is aliased to libiconv() in -liconv])
], [
PHP_CHECK_LIBRARY($iconv_lib_name, iconv, [
found_iconv=yes
], [], [
<snip>
fi
OTOTH it should be defined and have the effect to replace iconv(...)
to libiconv(...) for proper libiconv linking. (libiconv has function
named libiconv() not iconv())
php-5.4.0/ext/iconv/iconv.c:
#if defined(HAVE_LIBICONV) && defined(ICONV_ALIASED_LIBICONV)
#define iconv libiconv
#endif
I've applied attached patch and it get built fine.
*** Bug 410573 has been marked as a duplicate of this bug. *** (In reply to comment #13) > This code actually check iconv or libiconv not only for libc, but also > $LIBS already set. > > As Denis and I enabled libxml2, php added `xml2-config --libs` to > $LIBS, leading to confuse the test above. It lacked some description. xml2-config --libs return "-L/usr/lib -lxml2 -lz -lpthread -liconv -lm", so that the test pass with linking libiconv() using -liconv. (In reply to comment #15) > (In reply to comment #13) > > This code actually check iconv or libiconv not only for libc, but also > > $LIBS already set. > > > > As Denis and I enabled libxml2, php added `xml2-config --libs` to > > $LIBS, leading to confuse the test above. > > It lacked some description. xml2-config --libs return "-L/usr/lib -lxml2 -lz > -lpthread -liconv -lm", so that the test pass with linking libiconv() using > -liconv. it would make sense to use libxml-2.0.pc instead of xml2-config imho, the former supports Libs.private for static linking, while the latter seems to provide them regardless and produces overlinking (and, as a consequence, this problem). (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #13) > > > This code actually check iconv or libiconv not only for libc, but also > > > $LIBS already set. > > > > > > As Denis and I enabled libxml2, php added `xml2-config --libs` to > > > $LIBS, leading to confuse the test above. > > > > It lacked some description. xml2-config --libs return "-L/usr/lib -lxml2 -lz > > -lpthread -liconv -lm", so that the test pass with linking libiconv() using > > -liconv. > > it would make sense to use libxml-2.0.pc instead of xml2-config imho, the > former supports Libs.private for static linking, while the latter seems to > provide them regardless and produces overlinking (and, as a consequence, > this problem). Yes, but there's a lot of tests that can add -liconv... :( anyway, upstream already patched their source to reset LIBS. I'll apply this patch and re-KEYWORD ~x86-fbsd. http://git.php.net/?p=php-src.git;a=commitdiff;h=a6c95c8a00e9286ccc662e9682f9254e153d6833;hp=8684fb7facd8f5c1589996c1ebfd782f77c245ff I've stacked with adding patch. I think, it would be better to have the patch in php-patches-*.tar.bz2. I don't have access permission for the files. Could you add the patch to the files please? As I understand this thread, the patch is applied upstream. If so, it means it will be in the next version of PHP 5.x, which will hopefully be released next week. (In reply to comment #19) > As I understand this thread, the patch is applied upstream. If so, it means > it will be in the next version of PHP 5.x, which will hopefully be released > next week. OK, then I wait for it. Thanks. It's not in -5.3.11 and -5.4.1 :( It seems it will be in -5.3.12 maybe. Would it come some time soon? (In reply to comment #21) > It's not in -5.3.11 and -5.4.1 :( It seems it will be in -5.3.12 maybe. > Would it come some time soon? The micro versions are typically released once a month. Depends on how many bugs they discover in the rc phase. If this patch is not in 5.3.12_rc1 when released, let me know and I will add it to our patchset. Now it is unfortunately too late, since 5.3.12 will probably be released before I can do an -r1 (In reply to comment #22) > If this patch is not in 5.3.12_rc1 when released, let me know and I will add > it to our patchset. Now it is unfortunately too late, since 5.3.12 will > probably be released before I can do an -r1 It's not in -5.3.13 nor -5.4.3. (In reply to comment #23) > (In reply to comment #22) > > If this patch is not in 5.3.12_rc1 when released, let me know and I will add > > it to our patchset. Now it is unfortunately too late, since 5.3.12 will > > probably be released before I can do an -r1 > > It's not in -5.3.13 nor -5.4.3. These two versions are emergency security fixes. However, rc's are already out for .14 and .4, and as far as I can tell, the patch (or its equivalent) is there: http://git.php.net/?p=php-src.git;a=blob;f=acinclude.m4;h=adb9599ce4887b0a56852a91f255bf65e703fae5;hb=refs/heads/PHP-5.4#l2449 FWIW: I've keyworded php 5.3.13 and 5.4.3 ~amd64-fbsd and masked php[iconv] on amd64-fbsd profiles Now it get fixed. ~x86-fbsd added. |