Qt 4.8.6 does not currently build on uclibc, while 4.8.5 works (I use some programs using it). It fails to detect libiconv. Reproducible: Always Steps to Reproduce: 1. emerge -1 =dev-qt/qtcore-4.8.6-r2 Actual Results: * ERROR: dev-qt/qtcore-4.8.6-r2::gentoo failed (configure phase): * configure failed Expected Results: Qt 4.8.6 installed on system
Created attachment 403422 [details] emerge --info output
Created attachment 403424 [details] build.log from emerge
Created attachment 403924 [details, diff] qtcore-4.8.6-uclibc.patch I had to apply this patch to be able to build Qt. But why would the libiconv iconv function prototype change between uclibc and other libcs?
The "POSIX iconv auto-detection" test should succeed but it fails to link due to a missing -liconv. This is consistent with a recent eclass change. Do you have dev-libs/libiconv installed?
(In reply to Davide Pesavento from comment #4) > Do you have dev-libs/libiconv installed? Yes, I do have libiconv installed % emerge --search libiconv [ Results for search key : libiconv ] Searching... * dev-libs/libiconv Latest version available: 1.14-r1 Latest version installed: 1.14-r1 Size of files: 4868 KiB Homepage: http://www.gnu.org/software/libiconv/ Description: GNU charset conversion library for libc which doesn't implement it License: GPL-3 * virtual/libiconv Latest version available: 0-r2 Latest version installed: 0-r2 Size of files: 0 KiB Homepage: Description: Virtual for the GNU conversion library License: [ Applications found : 2 ]
*** Bug 553986 has been marked as a duplicate of this bug. ***
The attached patch worked for me on Arm/uClibc as well. pesa, I don't think this one is the usual missing -liconv type bug, it seems to be a const correctness issue with the libiconv header (vs the normal glibc provided one) which the patch works around.
(In reply to David Flogeras from comment #7) > The attached patch worked for me on Arm/uClibc as well. > > pesa, I don't think this one is the usual missing -liconv type bug, it seems > to be a const correctness issue with the libiconv header (vs the normal > glibc provided one) which the patch works around. I'm having success with 4.8.6-r2 provided I feed it LDFLAGS=-liconv via /etc/portage/package.env. It made it through my tinderbox run and produced a package: http://lilblue.freeharbor.net/dev-qt/qtcore-4.8.6-r2.tbz2 (In reply to David Flogeras from comment #7) > The attached patch worked for me on Arm/uClibc as well. > > pesa, I don't think this one is the usual missing -liconv type bug, it seems > to be a const correctness issue with the libiconv header (vs the normal > glibc provided one) which the patch works around. The build log in comment #2 suggests just a missing -liconv. The patch in comment #3 seems to be an issue of inconsistent const declaration. @Rene. Can you check what's going on here. I'm not seing a problem and thinking of closing this NEED INFO.
(In reply to Anthony Basile from comment #8) > The build log in comment #2 suggests just a missing -liconv. The patch in > comment #3 seems to be an issue of inconsistent const declaration. > > @Rene. Can you check what's going on here. I'm not seing a problem and > thinking of closing this NEED INFO. I looked again at the log I attached to this bug and I see the same failures in iconv tests during the configure phase as with Qt 5 I filed in bug #587062. This is not a missing iconv problem, but an inconsistent const declaration problem. We got confused because -liconv used to be forced into qt eclass under uclibc(-ng), so even when the tests failed, Qt was linked to libiconv anyway.
Qt4 is gone.
