diff options
author | Frederik Gladhorn <frederik.gladhorn@qt.io> | 2019-06-24 16:01:42 +0200 |
---|---|---|
committer | Frederik Gladhorn <frederik.gladhorn@qt.io> | 2019-10-03 19:49:48 +0000 |
commit | f9635567942071206f10430024895db6a127abf8 (patch) | |
tree | ba9aa7254cbe6faf6079a26c3cb4347826fd11d8 /gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/DESIGN | |
parent | accc0af6e4a66c598409c5ed22ba1e8f63fc96ae (diff) |
Remove gnuwin32 - it is provided through provisioning
Having a few windows specific tools in qt5.git was always strange. We
now provision the utilities to the machines, so remove them from
qt5.git.
[ChangeLog][General] GnuWin32 is no longer part of the Qt source code repositories.
Instead it can be downloaded from the upstream project at https://gnuwin32.sourceforge.net .
For convenience we also make a copy available here:
https://download.qt.io/development_releases/gnuwin32/gnuwin32.zip
The GnuWin32 tools are needed for building Qt from source on Windows.
Binary package downloads are not affected.
Task-number: QTBUG-73424
Change-Id: I9212cc2923343f4f84bcba9d1444a90e446dfb8a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Diffstat (limited to 'gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/DESIGN')
-rw-r--r-- | gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/DESIGN | 64 |
1 files changed, 0 insertions, 64 deletions
diff --git a/gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/DESIGN b/gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/DESIGN deleted file mode 100644 index 9ff2ad3a..00000000 --- a/gnuwin32/contrib/libiconv/1.9.2/libiconv-1.9.2-src/DESIGN +++ /dev/null @@ -1,64 +0,0 @@ -While some other iconv(3) implementations - like FreeBSD iconv(3) - choose -the "many small shared libraries" and dlopen(3) approach, this implementation -packs everything into a single shared library. Here is a comparison of the -two designs. - -* Run-time efficiency - 1. A dlopen() based approach needs a cache of loaded shared libraries. - Otherwise, every iconv_open() call will result in a call to dlopen() - and thus to file system related system calls - which is prohibitive - because some applications use the iconv_open/iconv/iconv_close sequence - for every single filename, string, or piece of text. - 2. In terms of virtual memory use, both approaches are on par. Being shared - libraries, the tables are shared between any processes that use them. - And because of the demand loading used by Unix systems (and because libiconv - does not have initialization functions), only those parts of the tables - which are needed (typically very few kilobytes) will be read from disk and - paged into main memory. - 3. Even with a cache of loaded shared libraries, the dlopen() based approach - makes more system calls, because it has to load one or two shared libraries - for every encoding in use. - -* Total size - In the dlopen(3) approach, every shared library has a symbol table and - relocation offset. All together, FreeBSD iconv installs more than 200 shared - libraries with a total size of 2.3 MB. Whereas libiconv installs 0.45 MB. - -* Extensibility - The dlopen(3) approach is good for guaranteeing extensibility if the iconv - implementation is distributed without source. (Or when, as in glibc, you - cannot rebuild iconv without rebuilding your libc, thus possibly - destabilizing your system.) - The libiconv package achieves extensibility through the LGPL license: - Every user has access to the source of the package and can extend and - replace just libiconv.so. - The places which have to be modified when a new encoding is added are as - follows: add an #include statement in iconv.c, add an entry in the table in - iconv.c, and of course, update the README and iconv_open.3 manual page. - -* Use within other packages - If you want to incorporate an iconv implementation into another package - (such as a mail user agent or web browser), the single library approach - is easier, because: - 1. In the shared library approach you have to provide the right directory - prefix which will be used at run time. - 2. Incorporating iconv as a static library into the executable is easy - - it won't need dynamic loading. (This assumes that your package is under - the LGPL or GPL license.) - - -All conversions go through Unicode. This is possible because most of the -world's characters have already been allocated in the Unicode standard. -Therefore we have for each encoding two functions: -- For conversion from the encoding to Unicode, a function called xxx_mbtowc. -- For conversion from Unicode to the encoding, a function called xxx_wctomb, - and for stateful encodings, a function called xxx_reset which returns to - the initial shift state. - - -All our functions operate on a single Unicode character at a time. This is -obviously less efficient than operating on an entire buffer of characters at -a time, but it makes the coding considerably easier and less bug-prone. Those -who wish best performance should install the Real Thing (TM): GNU libc 2.1 -or newer. - |