Daniel Macks wrote: [] > it is something in qt4-x11 itself that wants libiconv not just "want > it because use glib2 and glib2 is what actually wants it", so it's up > to qt4-x11 to pass that linker flag itself. Until now, it just got > lucky that glib2 was sloppy and published all the libs it used, even > the ones that were only internal-implementation details.
After some more interrogation of the suspects, I think you are right. qt4-x11 has tests for the existence of iconv, and it knows about two variants, iconv and gnu-libiconv. In the tests, it dutifully links with -liconv for both variants, but then when it creates src/corelib/Makefile using src/corelib/codecs/codecs.pri, it suddenly decides that it needs -liconv only for the gnu-libiconv variant and not for the iconv variant. At least, that's how I decipher that *.pri code. And since it had found that we are using the iconv variant, there is no -liconv on the linker line, unless it is brought in by some other dependency, like it used to be with glib2. Adding a line LIBS += -liconv to src/corelib/codecs/codecs.pri, for example using the line perl -pi.bak -e 's|contains\(QT_CONFIG,iconv\).*|$&\n LIBS += -liconv|' src/corelib/codecs/codecs.pri before configure in qt4-x11.info, lets the build go through for me. BTW, qt4-mac does not suffer from this problem, because when building corelibs/codecs, it thinks it is not on Unix and therefore defines its own iconv stuff locally without reading iconv.h nor linking to libiconv. -- Martin ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fink-users mailing list Fink-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-users
