-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[mailto:development-bounces+kai.koehne=digia@qt-project.org] On
Behalf Of Thiago Macieira
Sent: Thursday, March 07, 2013 8:34 PM
To: development@qt-project.org
Subject: Re: [Development] ICU
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[mailto:development-bounces+kai.koehne=digia@qt-project.org] On
Behalf Of Joseph Crowell
Sent: Thursday, February 07, 2013 1:56 AM
To: development@qt-project.org
Subject: Re: [Development] ICU
On quinta-feira, 7 de março de 2013 16.16.05, Koehne Kai wrote:
I'm not 100% happy with the patch though because we have an inherent timing
problem: ICU data might be accessed cached before QCoreApplication is
created and has opened the .dat file. This happens in fact already by
default, when
On Thursday 07 Mar 2013 16:16:05 Koehne Kai wrote:
On 02/06/2013 11:20 PM, Koehne Kai wrote:
[...]
That is what we should do indeed. I learned from
http://userguide.icu-project.org/icudata
that one can also ship the ICU data in separate .data files, located in
a ICU
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[mailto:development-bounces+kai.koehne=digia@qt-project.org] On
Behalf Of Joseph Crowell
Sent: Thursday, February 07, 2013 1:56 AM
To: development@qt-project.org
Subject: Re: [Development] ICU
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[mailto:development-bounces+kai.koehne=digia@qt-project.org] On
Behalf Of Thiago Macieira
Sent: Tuesday, February 05, 2013 6:42 AM
To: development@qt-project.org
Subject: Re: [Development] ICU
04.02.2013, 18:37, Koehne Kai kai.koe...@digia.com:
Hi,
Importing ICU into qtbase is fine with me. Anyhow, I don't particular like
hard dependency to ICU from Qt5Core, since it forces everyone deploying a
Windows helloworld to also ship icudt49.dll with 17,5 MB (!).
Note that it's
@qt-project.org] On
Behalf Of Thiago Macieira
Sent: Monday, January 14, 2013 4:52 PM
To: development@qt-project.org
Subject: Re: [Development] ICU and Windows
On segunda-feira, 14 de janeiro de 2013 13.02.46, Shaw Andy wrote:
Therefore I would like to propose that for 5.0.1 we simply modify
: Monday, January 14, 2013 4:52 PM
To: development@qt-project.org
Subject: Re: [Development] ICU and Windows
On segunda-feira, 14 de janeiro de 2013 13.02.46, Shaw Andy wrote:
Therefore I would like to propose that for 5.0.1 we simply modify the
pro file so that it expects a d after the library
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[..]
Importing ICU into qtbase is fine with me. Anyhow, I don't particular like
hard dependency to ICU from Qt5Core, since it forces everyone deploying a
Windows helloworld to also ship icudt49.dll
To: development@qt-project.org
Subject: Re: [Development] ICU and Windows
On segunda-feira, 14 de janeiro de 2013 13.02.46, Shaw Andy wrote:
Therefore I would like to propose that for 5.0.1 we simply modify the
pro file so that it expects a d after the library name for the debug
version
On segunda-feira, 4 de fevereiro de 2013 15.30.24, Knoll Lars wrote:
Importing ICU into qtbase is fine with me. Anyhow, I don't particular like
hard dependency to ICU from Qt5Core, since it forces everyone deploying a
Windows helloworld to also ship icudt49.dll with 17,5 MB (!).
No, please
On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote:
Which is not always that easy... if a library function returns, say, an
simple std::string *by value*, then who will destroy the allocated memory?
It's really too easy to break something, somwhere, causing a random crash
On Mon, Jan 14, 2013 at 9:35 AM, Thiago Macieira
thiago.macie...@intel.comwrote:
On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote:
Which is not always that easy... if a library function returns, say, an
simple std::string *by value*, then who will destroy the allocated
14.01.2013, 15:56, Pau Garcia i Quiles pgqui...@elpauer.org:
On Mon, Jan 14, 2013 at 9:35 AM, Thiago Macieira thiago.macie...@intel.com
wrote:
On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote:
Which is not always that easy... if a library function returns, say, an
simple
On Mon, Jan 14, 2013 at 1:31 PM, Konstantin Tokarev annu...@yandex.ruwrote:
On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote:
Which is not always that easy... if a library function returns, say, an
simple std::string *by value*, then who will destroy the allocated
] ICU and Windows
On Mon, Jan 14, 2013 at 1:31 PM, Konstantin Tokarev
annu...@yandex.rumailto:annu...@yandex.ru wrote:
On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote:
Which is not always that easy... if a library function returns, say, an
simple std::string *by value
On 01/12/2013 09:26 AM, Sascha Cunz wrote:
Am Freitag, 11. Januar 2013, 23:07:25 schrieb Shaw Andy:
[...]
Microsoft in the past has also said that you should keep the
-MD(d)/-MT(d)
setting consistent so it is the same across all libraries and
applications,
[...]
Which is cool, if you can
Le 11/01/2013 16:50, Thiago Macieira a écrit :
On sexta-feira, 11 de janeiro de 2013 13.32.35, Shaw Andy wrote:
Unfortunately this is what is happening now if ICU is linked in, ICU will
always use the release version so if Qt is built in debug mode then it will
end up mixing the C runtime
As I was investigating a different problem I came across a bigger issue
regarding ICU on Windows. The problem is that when ICU is linked against on
Windows it links against the same copy of the library even if it is building
for release which causes a problem with C runtime libraries on
On sexta-feira, 11 de janeiro de 2013 13.32.35, Shaw Andy wrote:
Unfortunately this is what is happening now if ICU is linked in, ICU will
always use the release version so if Qt is built in debug mode then it will
end up mixing the C runtime libraries.
Either way I feel that this needs to
On Friday 11 Jan 2013 13:32:35 Shaw Andy wrote:
Since ICU doesn't provide the debug version of the libraries in their binary
packages then this means that either the user has to build them themselves
(which means modifying the target as well since the output for debug and
release defaults to
11.01.2013, 20:29, John Layt jl...@kde.org:
On Friday 11 Jan 2013 13:32:35 Shaw Andy wrote:
Since ICU doesn't provide the debug version of the libraries in their binary
packages then this means that either the user has to build them themselves
(which means modifying the target as well
On sexta-feira, 11 de janeiro de 2013 13.32.35, Shaw Andy wrote:
Unfortunately this is what is happening now if ICU is linked in, ICU will
always use the release version so if Qt is built in debug mode then it will
end up mixing the C runtime libraries.
Either way I feel that this
[...]
Microsoft in the past has also said that you should keep the -MD(d)/-MT(d)
setting consistent so it is the same across all libraries and applications,
[...]
Which is cool, if you can manage it. But it's far from what happens in the
real world.
In the real world you have
Am Freitag, 11. Januar 2013, 23:07:25 schrieb Shaw Andy:
[...]
Microsoft in the past has also said that you should keep the
-MD(d)/-MT(d)
setting consistent so it is the same across all libraries and
applications,
[...]
Which is cool, if you can manage it. But it's far
Hello Qt developers,
so Qt 5 for windows doesn't include libICU sources but it requires it to
build webkit.
Unless other dependencies like Perl and Python, which can be installed once
in the system, libICU must be configured,built, and installed for every
compiler toolset/mkspec you are going to
27 matches
Mail list logo
