ext/iconv/iconv.o: In function `_php_iconv_appendl': iconv.c:(.text+0x510): undefined reference to `iconv' ... Reproducible: Always Steps to Reproduce: 1. emerge =dev-lang/php-5.2.14 2. 3. Actual Results: Failed to emerge. Expected Results: emerged dev-lang/php
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.
