No application window displayed because of iconv dependence

[Andi Cristian Șerbănescu]

Hello,

I tried building 0.2.2beta2 on my system. It compiled successfully, but running it in a terminal window won't do anything (it doesn't crash; it just grabs the shell, but nothing displays). Even passing bad options won't show an error (something like "-graphicssystem bogus" would do so).

I'm running Gentoo Linux 3.2.12-gentoo on x86_64, multilib profile, with gcc-4.5.3, glibc-2.14.1-r3 and qt-*-4.7.4-r1. All my packages are locally built, and I tend to disable things unless I need them (which may have something to do with it, but I don't know what). I tried rebuilding Qt with more options and upgrading to 4.8 but with no results.

Building different versions of qpdfview, I found out that the bug crept in somewhere between 0.2.1 and 0.2.2alpha1 (even though 0.2.1 is newer and 0.2.2alpha1 older, the first on works and the second doesn't).

The following options were used to configure qt-core (taken from the ebuild; a few are explicitly turned off by me, most are implicit): "-no-glib -no-iconv -no-optimized-qmake -no-openssl -no-qt3support -no-javascript-jit -no-xkb -no-fontconfig -no-xrender -no-xrandr -no-xfixes -no-xcursor -no-xinerama -no-xshape -no-sm -no-opengl -no-nas-sound -no-dbus -no-cups -no-gif -no-libpng -no-libmng -no-libjpeg -system-zlib -no-webkit -no-phonon -no-xmlpatterns -no-freetype -no-libtiff -no-accessibility -no-fontconfig -no-opengl -no-svg -no-gtkstyle -no-phonon-backend -no-script -no-scripttools -no-cups -no-xsync -no-xinput -no-multimedia".

And qt-gui was configured with the following (the same applies): "-no-accessibility -no-cups -no-glib -no-libmng -no-nis -no-libtiff -no-qdbus -no-dbus -no-egl -no-qt3support -no-gtkstyle -no-xinerama -qt-gif -system-libpng -system-libjpeg -no-sql-mysql -no-sql-psql -no-sql-ibase -no-sql-sqlite -no-sql-sqlite2 -no-sql-odbc -xrender -xrandr -xkb -xshape -sm -no-svg -no-webkit -no-phonon -no-opengl".

Maybe I should contact the Gentoo devs too, but I have no idea exactly to whom should I forward this (0.2beta2 is the latest in Portage). If I can help you with other information, please ask.

Andi Șerbănescu

[Adam Reichold (adamreichold)]

Well, I think the main change w.r.t. the MainWindow from 0.2 to 0.2.2beta2 is that it is created on the heap instead of the stack but I don't how that could make a difference. (And did not yet change in 0.2.2alpha1.)

But I also have to admit that I do not posses a detailed knowledge of all these configurations options. (Some of them seem contradictory, i.e. "-no-sm" in Core but "-sm" in GUI? But as I said, I just don't really know.)

I also have to admit that I pretty much have no idea what could cause this and the most helpful information would probably be provided by a debugging session to find out how far exactly the initialization of the MainWindow class comes. (Because it does not exit, I assume it enters the main event loop at least.)

(One very far fetched idea would be to remove the folder "~/.config/qpdfview" as the program tries to restore its window state on startup. Maybe something got messed up there?)

[Adam Reichold (adamreichold)]

As users of Arch Linux (like myself) do not seem to have that particular problem, maybe you could use the configuration options of it Qt package (The source is available at "https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/qt".) as a baseline and try to get as close to your desired configuration as possible to find the problematic option. (If it actually is a configuration problem. I do not want to rule out a programming mistake.) But this could of course be quite tedious.

[Andi Cristian Șerbănescu (ac-serbanescu)]

It didn't work (the part about removing the configuration directory). It built in Ubuntu, however, and a Gentoo dev built it too, and it runs just fine for him. I'll try copying his build (as soon as I get the details) before doing anything else, especially debugging, since I have no idea how to debug Qt :) (Also, since I've tried it out, I'll also be posting some opinions to the mailing list some time now.)

[Andi Cristian Șerbănescu (ac-serbanescu)]

I did it. I activated various options indiscriminately, so I don't know exactly which one is the culprit. I'll refine them to pinpoint the exact cause.

[Adam Reichold (adamreichold)]

Ok, I will wait and see what the problem actually is and mark this as invalid if it is a configuration problem instead of a bug in qpdfview. Otherwise, we'll see whether something can be done to make the program work in more diverse environments or maybe at least add a note to the README file on the specific configuration option.

[Andi Cristian Șerbănescu (ac-serbanescu)]

It needs qt-core to be compiled with support for iconv (what's it needed for, anyway?).

[Adam Reichold (adamreichold)]

iconv is used to convert between different character encodings and there are for example some strings in the in the interface that have to be read from the source as UTF-8 to be displayed correctly. Probably also depends on the locale that your system uses, but I would really consider iconv a necessity for a translated/internationalized interface.

[Andi Cristian Șerbănescu (ac-serbanescu)]

I use en_GB.UTF-8. I understand it's used to convert to and from (and between) non-unicode text, am I right? Anyway, nothing wanted qt to have it until now...