Qt

Qt

[Andreas Enge]

Hi,

I just pushed a patch for Qt 5.1.1. It builds on my machine, but as there
is no application using it so far, it may or may not work. Also, the build
uses sse/sse2/... instructions according to what is available on the processor;
we might wish to disable all or at least the most advanced of them in the
long run. For the time being, I would leave them in, and once we have
a qt application, check whether it works on different processors.

A next step would be to add qt 4.8.5, as I think this version is still
used more widely so far.

Andreas

Re: Qt

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> I just pushed a patch for Qt 5.1.1.

Good, congratulations!

> It builds on my machine, but as there is no application using it so
> far, it may or may not work. Also, the build uses
> sse/sse2/... instructions according to what is available on the
> processor; we might wish to disable all or at least the most advanced
> of them in the long run.

Yes, as for GMP and FFTW.  Otherwise, when using substitutes from Hydra,
one could end up with binaries that raise SIGILL on their machine.

> For the time being, I would leave them in, and once we have a qt
> application, check whether it works on different processors.

If it’s a matter of adding the right configure flag, I’d do it before
it bites.

> A next step would be to add qt 4.8.5, as I think this version is still
> used more widely so far.

OK.

Thanks for daring to dive into that!

Ludo’.

Re: Qt

[Andreas Enge]

On Tue, Oct 08, 2013 at 11:05:04PM +0200, Ludovic Courtès wrote:
> Andreas Enge <andreas@enge.fr> skribis:
> > Also, the build uses
> > sse/sse2/... instructions according to what is available on the
> > processor; we might wish to disable all or at least the most advanced
> > of them in the long run.
> If it’s a matter of adding the right configure flag, I’d do it before
> it bites.

The following will leave out any special instructions, as far as I can see:
+                              "-no-sse2"
+                              "-no-sse3"
+                              "-no-ssse3"
+                              "-no-sse4.1"
+                              "-no-sse4.2"
+                              "-no-avx"
+                              "-no-avx2"
+                              "-no-neon"
+                              "-no-mips_dsp"
+                              "-no-mips_dspr2"))))

I do not know how much this slows down qt applications. According to wikipedia,
sse2 arrived in 2001. So one could argue that adding it would exclude almost
no machines.

Andreas

Re: Qt

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, Oct 08, 2013 at 11:05:04PM +0200, Ludovic Courtès wrote:
>> Andreas Enge <andreas@enge.fr> skribis:
>> > Also, the build uses
>> > sse/sse2/... instructions according to what is available on the
>> > processor; we might wish to disable all or at least the most advanced
>> > of them in the long run.
>> If it’s a matter of adding the right configure flag, I’d do it before
>> it bites.
>
> The following will leave out any special instructions, as far as I can see:
> +                              "-no-sse2"
> +                              "-no-sse3"
> +                              "-no-ssse3"
> +                              "-no-sse4.1"
> +                              "-no-sse4.2"
> +                              "-no-avx"
> +                              "-no-avx2"
> +                              "-no-neon"
> +                              "-no-mips_dsp"
> +                              "-no-mips_dspr2"))))
>
> I do not know how much this slows down qt applications. According to wikipedia,
> sse2 arrived in 2001. So one could argue that adding it would exclude almost
> no machines.

Yes, you may be right for SSE2 (especially considering the fact that
this kind of software is typically used on fairly recent machines.)

Ludo’.

Re: Qt

[Andreas Enge]

On Thu, Oct 10, 2013 at 03:09:09PM +0200, Ludovic Courtès wrote:
> Andreas Enge <andreas@enge.fr> skribis:
> > I do not know how much this slows down qt applications. According to wikipedia,
> > sse2 arrived in 2001. So one could argue that adding it would exclude almost
> > no machines.
> Yes, you may be right for SSE2 (especially considering the fact that
> this kind of software is typically used on fairly recent machines.)

Finally, I disabled everything special. As this is not a number crunching
library, I would like to be convinced of the usefulness of SSE.

Andreas

Re: Qt

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Thu, Oct 10, 2013 at 03:09:09PM +0200, Ludovic Courtès wrote:
>> Andreas Enge <andreas@enge.fr> skribis:
>> > I do not know how much this slows down qt applications. According to wikipedia,
>> > sse2 arrived in 2001. So one could argue that adding it would exclude almost
>> > no machines.
>> Yes, you may be right for SSE2 (especially considering the fact that
>> this kind of software is typically used on fairly recent machines.)
>
> Finally, I disabled everything special.

You can assume SSE2 on x86_64, as _all_ x86_64 processors have it.  In
fact, the C function calling conventions of SysV x86_64 psABI (used by
GNU/Linux) specify that the SSE2 registers are used for passing floating
point values as arguments.

> As this is not a number crunching library, I would like to be
> convinced of the usefulness of SSE.

Qt is not a number crunching library, but I suspect it _does_ have image
rendering code, where SIMD instruction sets such as SSE2 can make a
dramatic difference in performance.

    Regards,
      Mark

Re: Qt

[Andreas Enge]

On Thu, Oct 10, 2013 at 06:19:09PM -0400, Mark H Weaver wrote:
> You can assume SSE2 on x86_64, as _all_ x86_64 processors have it.

Very well. Here is the list of options to potentially turn off for Qt 4.8.5:
                              "-no-mmx"
                              "-no-3dnow"
                              "-no-sse"
                              "-no-sse2"
                              "-no-sse3"
                              "-no-ssse3"
                              "-no-sse4.1"
                              "-no-sse4.2"
                              "-no-avx"
                              "-no-neon"
So I can enable mmx, 3dnow, sse and sse2 on x86_64? Or only sse and sse2?
Or only sse2?

Qt 5.1.1 also has the following:
                              "-no-avx2"
                              "-no-mips_dsp"
                              "-no-mips_dspr2"
How about mips? We agreed to target it at loongson for the time being,
then could we enable one or both of the mips related options?

Andreas

Re: Qt

[Andreas Enge]

So I added Qt 4.8.5, after disabling a few tests requiring an X server -
adding xorg-server as an input was not enough, as the server would not be
started by the tests, but supposed to be already running. Two "hello world"
programs I found in a tutorial compile.

The gui program complains about a missing icui18n library. Strace shows the
following:

open("/nix/store/z70fv39wa8yrvvqq9zfidsh86z72p4gr-qt-4.8.5/lib/libicui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/lib/libicui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/52998i0m4gr7k35lni8fmg591zsyqamv-gcc-4.7.3/lib/libicui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/g4cs0ssg7ry4da1615947ild5l4wv6ba-zlib-1.2.7/lib/libicui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/dly2cqqprdsb4fqabrw0bxm1n42vpi6w-glib-2.38.0/lib/libicui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/lib/libicui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/z70fv39wa8yrvvqq9zfidsh86z72p4gr-qt-4.8.5/lib/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/lib/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/52998i0m4gr7k35lni8fmg591zsyqamv-gcc-4.7.3/lib/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/g4cs0ssg7ry4da1615947ild5l4wv6ba-zlib-1.2.7/lib/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/dly2cqqprdsb4fqabrw0bxm1n42vpi6w-glib-2.38.0/lib/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/lib/libicui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/z70fv39wa8yrvvqq9zfidsh86z72p4gr-qt-4.8.5/lib/icui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/lib/icui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/52998i0m4gr7k35lni8fmg591zsyqamv-gcc-4.7.3/lib/icui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/g4cs0ssg7ry4da1615947ild5l4wv6ba-zlib-1.2.7/lib/icui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/dly2cqqprdsb4fqabrw0bxm1n42vpi6w-glib-2.38.0/lib/icui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/lib/icui18n.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/z70fv39wa8yrvvqq9zfidsh86z72p4gr-qt-4.8.5/lib/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/lib/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/52998i0m4gr7k35lni8fmg591zsyqamv-gcc-4.7.3/lib/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/g4cs0ssg7ry4da1615947ild5l4wv6ba-zlib-1.2.7/lib/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/dly2cqqprdsb4fqabrw0bxm1n42vpi6w-glib-2.38.0/lib/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/lib/icui18n", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 4

icu4c was present at the time of compilation, but is not listed as a reference:

$$ ./pre-inst-env guix gc --references /nix/store/z70fv39wa8yrvvqq9zfidsh86z72p4gr-qt-4.8.5

/nix/store/2332f9jmabldwz08lqj9yd8znrx9z125-libpng-1.5.17
/nix/store/3xkdzldlqm4sa2p4czjbnybdwq47qlw2-fontconfig-2.10.93
/nix/store/52998i0m4gr7k35lni8fmg591zsyqamv-gcc-4.7.3
/nix/store/8cpwgsdx2njpkdj20i963zfxs0fyqkvi-libjpeg-8d
/nix/store/arsxjcl3kdxxjxf7s1nsvfczis6pckm3-libxrender-0.9.7
/nix/store/asmki6g7ca64sdlcf6ahnjxvxg2x6sgv-libx11-1.5.0
/nix/store/b3c1z47c201gz8gnx5553kw2qb4qdq3b-freetype-2.4.11
/nix/store/dly2cqqprdsb4fqabrw0bxm1n42vpi6w-glib-2.38.0
/nix/store/g4cs0ssg7ry4da1615947ild5l4wv6ba-zlib-1.2.7
/nix/store/i9b6q8wciapn69wifmb1xgpikj4ljjzy-alsa-lib-1.0.27.1
/nix/store/l8bnfq6n6hb2wvx0kxdy141jna8mkns3-mysql-5.1.54
/nix/store/lhb68hrv6hcris5bbr7y894c9g8fj558-libxext-1.3.1
/nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18
/nix/store/vmajpkk5ih03g0wik16693fkc638if8k-mesa-8.0.5
/nix/store/z70fv39wa8yrvvqq9zfidsh86z72p4gr-qt-4.8.5

ldd on the offending binary shows no dependency on anything icu related,
and installing icu4c in the user profile does not have any effect.

If I add $HOME/.guix-profile/lib to LD_LIBRARY_PATH, the problem disappears.
I wonder if some dlopen magic is involved. Do you see a solution from
this description?

Andreas

Re: Qt

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> So I added Qt 4.8.5, after disabling a few tests requiring an X server -
> adding xorg-server as an input was not enough, as the server would not be
> started by the tests, but supposed to be already running.

I wonder how people address this in general.  Perhaps we could start
xvfb in a pre-check phase if that’s enough?

> Two "hello world" programs I found in a tutorial compile.

Neat.

> The gui program complains about a missing icui18n library. Strace shows the
> following:

[...]

> open("/etc/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

What’s this?!  Would be good to know where it comes from.  Normally our
glibc doesn’t look for ld.so.cache (see ‘glibc-no-ld-so-cache.patch’.)


[...]

> icu4c was present at the time of compilation, but is not listed as a reference:
>
> $$ ./pre-inst-env guix gc --references /nix/store/z70fv39wa8yrvvqq9zfidsh86z72p4gr-qt-4.8.5
>
> /nix/store/2332f9jmabldwz08lqj9yd8znrx9z125-libpng-1.5.17
> /nix/store/3xkdzldlqm4sa2p4czjbnybdwq47qlw2-fontconfig-2.10.93
> /nix/store/52998i0m4gr7k35lni8fmg591zsyqamv-gcc-4.7.3
> /nix/store/8cpwgsdx2njpkdj20i963zfxs0fyqkvi-libjpeg-8d
> /nix/store/arsxjcl3kdxxjxf7s1nsvfczis6pckm3-libxrender-0.9.7
> /nix/store/asmki6g7ca64sdlcf6ahnjxvxg2x6sgv-libx11-1.5.0
> /nix/store/b3c1z47c201gz8gnx5553kw2qb4qdq3b-freetype-2.4.11
> /nix/store/dly2cqqprdsb4fqabrw0bxm1n42vpi6w-glib-2.38.0
> /nix/store/g4cs0ssg7ry4da1615947ild5l4wv6ba-zlib-1.2.7
> /nix/store/i9b6q8wciapn69wifmb1xgpikj4ljjzy-alsa-lib-1.0.27.1
> /nix/store/l8bnfq6n6hb2wvx0kxdy141jna8mkns3-mysql-5.1.54
> /nix/store/lhb68hrv6hcris5bbr7y894c9g8fj558-libxext-1.3.1
> /nix/store/shamfhyg9hcac63y3bll9p50ixxid8vb-glibc-2.18
> /nix/store/vmajpkk5ih03g0wik16693fkc638if8k-mesa-8.0.5
> /nix/store/z70fv39wa8yrvvqq9zfidsh86z72p4gr-qt-4.8.5
>
> ldd on the offending binary shows no dependency on anything icu related,
> and installing icu4c in the user profile does not have any effect.
>
> If I add $HOME/.guix-profile/lib to LD_LIBRARY_PATH, the problem disappears.
> I wonder if some dlopen magic is involved. Do you see a solution from
> this description?

libicu4c is a dependency of Qt, right?

If so, I would make sure that it’s NEEDed by libqt.so, and that it’s in
its RUNPATH.  To do that, run:

  objdump -x libqt.so | grep -E '(NEED|PATH)'

If it’s not NEEDed, then -licu4c must be added on the link command for
libqt.so.

If it’s not in the RUNPATH, then -Wl,-rpath=/path/to/icu4c/lib must be
added to the libqt.so ld flags.

HTH,
Ludo’.

Re: Qt

[Andreas Enge]

On Sat, Oct 12, 2013 at 09:38:08PM +0200, Ludovic Court??s wrote:
> I wonder how people address this in general.  Perhaps we could start
> xvfb in a pre-check phase if that’s enough?

(Something is weird with your character encoding. Or with my character
decoding?)

I think that people either do not run "make check", or they have an X server
at the time of compiling and checking graphic libraries...
 
> > The gui program complains about a missing icui18n library. Strace shows the
> > following:
> libicu4c is a dependency of Qt, right?

Yes.

> If so, I would make sure that it’s NEEDed by libqt.so, and that it’s in
> its RUNPATH.  To do that, run:
>   objdump -x libqt.so | grep -E '(NEED|PATH)'

Hm, which libqt.so? There are 20 libQt*.so! Precisely:
libQt3Support.so     libQtDesignerComponents.so  libQtNetwork.so      libQtSvg.so
libQtCLucene.so      libQtDesigner.so            libQtOpenGL.so       libQtTest.so
libQtCore.so         libQtGui.so                 libQtScript.so       libQtWebKit.so
libQtDBus.so         libQtHelp.so                libQtScriptTools.so  libQtXmlPatterns.so
libQtDeclarative.so  libQtMultimedia.so          libQtSql.so          libQtXml.so

Anyway, objdump on none of them yields anything after piped through "grep icu".

The problem of not finding the icu library was not critical, by the way;
a warning was printed on the console, and the "hello world" program worked
nonetheless.

Andreas

Re: Qt

[Andreas Enge]

On Sat, Oct 12, 2013 at 11:25:38PM +0200, Andreas Enge wrote:
> (Something is weird with your character encoding. Or with my character
> decoding?)

My character encoding. LC_ALL=C is good for avoiding German error messages
to be sent to mailing lists, but UTF-8 is better for the rest.

Andreas

Re: Qt

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sat, Oct 12, 2013 at 09:38:08PM +0200, Ludovic Court??s wrote:

[...]

>> If so, I would make sure that it’s NEEDed by libqt.so, and that it’s in
>> its RUNPATH.  To do that, run:
>>   objdump -x libqt.so | grep -E '(NEED|PATH)'
>
> Hm, which libqt.so? There are 20 libQt*.so! Precisely:
> libQt3Support.so     libQtDesignerComponents.so  libQtNetwork.so      libQtSvg.so
> libQtCLucene.so      libQtDesigner.so            libQtOpenGL.so       libQtTest.so
> libQtCore.so         libQtGui.so                 libQtScript.so       libQtWebKit.so
> libQtDBus.so         libQtHelp.so                libQtScriptTools.so  libQtXmlPatterns.so
> libQtDeclarative.so  libQtMultimedia.so          libQtSql.so          libQtXml.so
>
> Anyway, objdump on none of them yields anything after piped through "grep icu".

(Should be ‘objdump -x’.)

Could you look for -licu in the Qt build log, to see which of those
shared libs is meant to be linked against it?

Thanks,
Ludo’.

Re: Qt

[Andreas Enge]

On Sun, Oct 13, 2013 at 03:54:16PM +0200, Ludovic Courtès wrote:
> Could you look for -licu in the Qt build log, to see which of those
> shared libs is meant to be linked against it?

None of them, as far as I can tell.

The only place where I found 'licu' is the following:

ICU auto-detection... ()
g++ -c -pipe -O2 -Wall -W  -I../../../mkspecs/linux-g++ -I. -o icu.o icu.cpp
g++ -Wl,-O1 -o icu icu.o     -licuuc -licui18n
ICU enabled.

This is during the configure phase.

The only interesting lines containing icu are the following:
g++ -c -include .pch/release-shared/QtCore -pipe -pthread -I/nix/store/dly2cqqprdsb4fqabrw0bxm1n42vpi6w-glib-2.38.0/include/glib-2.0 -I/nix/store/dly2cqqprdsb4fqabrw0bxm1n42vpi6w-glib-2.38.0/lib/glib-2.0/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\"\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared -o 
 .obj/release-shared/qlocale_icu.o tools/qlocale_icu.cpp

and another one
g++ ... -o libQtCore.so.4.8.5 ... .obj/release-shared/qlocale_icu.o ...

So at least this gives us the library.

And qlocale_icu.c contains this:
        // resolve libicui18n
        QLibrary lib(QLatin1String("icui18n"), QLatin1String(U_ICU_VERSION_SHORT));
        lib.setLoadHints(QLibrary::ImprovedSearchHeuristics);
        if (!lib.load()) {
            qWarning() << "Unable to load library icui18n" << lib.errorString();
            status = ErrorLoading;
            return false;
        }
and
        // resolve libicuuc
        QLibrary ucLib(QLatin1String("icuuc"), QLatin1String(U_ICU_VERSION_SHORT));
        ucLib.setLoadHints(QLibrary::ImprovedSearchHeuristics);
        if (!ucLib.load()) {
            qWarning() << "Unable to load library icuuc" << ucLib.errorString();
            status = ErrorLoading;
            return false;

So indeed this looks like dlopen at run time. ldd on libQt5Core.so shows that
in Qt 5, the library is explicitly linked with the icu libraries.

Andreas

Re: Qt

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> So indeed this looks like dlopen at run time. ldd on libQt5Core.so shows that
> in Qt 5, the library is explicitly linked with the icu libraries.

So I would patch Qt 4 to explicitly link libQt4Core.so (whatever it’s
called) against libicu as well.  That will make sure it’s found at run
time.

HTH,
Ludo’.

Re: Qt

[Andreas Enge]

On Sun, Oct 13, 2013 at 10:46:47PM +0200, Ludovic Courtès wrote:
> Andreas Enge <andreas@enge.fr> skribis:
> > So indeed this looks like dlopen at run time. ldd on libQt5Core.so shows that
> > in Qt 5, the library is explicitly linked with the icu libraries.
> So I would patch Qt 4 to explicitly link libQt4Core.so (whatever it’s
> called) against libicu as well.  That will make sure it’s found at run
> time.

No idea how to do this with the cmake build system...

Andreas

Re: Qt

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, Oct 13, 2013 at 10:46:47PM +0200, Ludovic Courtès wrote:
>> Andreas Enge <andreas@enge.fr> skribis:
>> > So indeed this looks like dlopen at run time. ldd on libQt5Core.so shows that
>> > in Qt 5, the library is explicitly linked with the icu libraries.
>> So I would patch Qt 4 to explicitly link libQt4Core.so (whatever it’s
>> called) against libicu as well.  That will make sure it’s found at run
>> time.
>
> No idea how to do this with the cmake build system...

Perhaps by adding -licu to the relevant cmake-generated Makefile, after
the ‘configure’ phase?  (Easier said than done.)

Ludo’.

Re: Qt

[Andreas Enge]

On Mon, Nov 11, 2013 at 09:36:55PM +0100, Ludovic Courtès wrote:
> Perhaps by adding -licu to the relevant cmake-generated Makefile, after
> the ‘configure’ phase?  (Easier said than done.)

This is finally fixed in commit 47e225c, thanks to the hackathon.

Andreas